Once you have successfully installed the yuuvis® RAD metrics-manager and opened Kibana in your browser, you are automatically forwarded to the "metricsMetrics-dashboard" Dashboard in the "Dashboards" Dashboard section of Kibana. Here, you will find a predefinded predefined set of visualizations of yuuvis® metrics, as well as the status of the hardware resources of your servers. The following picture shows you an exemplary view of the metricsMetrics-dashboardDashboard. Below the picture, each yellow highlighted visualization/point of interest (POI) highlighted in yellow is explained in detaileddetail.
(1) This is the menu section. Click on it to naviagte navigate to other dashboards, sections (Discover, VisualisationsVisualizations), or the mangement - management – or, if already opened before, restore the previously opened dashboards.
(2) This is the time range selector. Click on the arrow - down symbol icon to choose select your time range. It is very important to keep in mind that all visualizations shown only represent the data that corresponds to the here selected time range. If you have empty visualizations or you think some data is missing, your time range might be too small.
(3) This is the navigation bar within in the metricsMetrics-dashboardsDashboard. Click on any dashboard - title to switch to it. The specialized dashboards may contain more visualizations than shown on the overview dashboards.
(4) This visualization shows the CPU utilization of each one of your server servers that runs metricbeat. The value shown is the average over the entire chosen selected time range ((2)). (You can change intervals for the green, yellow and red zones in the visualization editor, but only for the entire visualization and not for each individual tacho.)
(5) This visualization shows the RAM utilization of each one of your server servers that runs metricbeat. The The value shown is the average over the entire chosen selected time range ((2)). 100% means the RAM is completely utilized. (You can change intervals for the green, yellow and red zones in the visualization editor.)
(6) This visualization shows the course of the CPU utilization of each one of your server servers that runs metricbeat over the chosen selected time range. The time range is subdivided into single buckets that aggregate its data. The amount of time that each bucket represents is automatically determined by kibana Kibana so that the entire diagram fits the available space. Each dot in the diagram represents one bucket. The actual bucket size is the difference between two dots. The value of each dot is the average CPU utilization of the depicted server over the time that the bucket represents.
| Info | ||
|---|---|---|
| ||
Zoom in the time range: Course Line Filtering/Color: |
(7) This visualization shows the course of the RAM utilization of each one of your server servers that runs metricbeat over the chosen selected time range. The visualization behaves analogous to to (6).
(8) This visualization shows the course of how many bytes (on average over the bucket size) were read on each of the hard drive partitions of each server running metricbeat.
...
(11) This visualization shows the course of how much CPU time in percent (on average over the bucket size) was utilized by each (operating system) process of each server running metricbeat. Reduced to the TOP top 10 processes over all servers.
(12) This visualization shows the course of how much RAM space in percent (on average over the bucket size) was utilized by each (operating system) process of each server running metricbeat. Reduced to the TOP top 10 processes over all servers.
...
(18) This indicates that the below following visualizations are all related to elasticsearchElasticsearch.
(19) This visualization shows the status of each elasticsearch Elasticsearch cluster that is monitored by a server running metricbeat. (Usually this is only one "es-red" cluster used by yuuvis® RAD.)
(20) This visualization shows the status of each elasticsearch Elasticsearch index that is part of a cluster shown in (19).
...
(22) This visualization shows the course of the number of documents (on average over the bucket size) that the enaiored_* index contained. (AttentionNote: The number of documents in elasticsearch Elasticsearch can be higher than the number of dms - objects because lists and tables are saved sub-documents in elasticsearch Elasticsearch that also count as documents.)
(23) This visualization shows the course of the duration (on average over the bucket size) that of each garbace garbage collection run of the elasticsearch Elasticsearch JDK took.
(24) This indicates that the below following visualizations are all related to yuuvis® RAD itself.
(25) This visualization shows how many different users and sessions (on average over the bucket size) were active during the chosen selected time range. With users, the unique login - names are meant. With sessions, the unique session - ids are meant. So for example, if one user logs into the client with his/her their browser and also has an agent that is logged in, then there will be one active user but two active sessions.
(26) This visualization shows the course of how many REST-API requests each user (login - name) has made (summed up per bucket). This means either implicitly by using the client, the agent, etc. or explicitly by directly sending a request to the API. It is ordered by the total amount of calls made, descending.
(27) This metric shows the count of how many different users (i.e., login - names) made at least one call over the entire selected time range chosen.
(28) This metric shows the count of how many different sessions (i.e., session - ids) appeared in at least one request over the entire selected time range chosen.
(29) This visualization shows the course of how many messages each queue of the messaging service contained - – on average over the bucket size. This visualization is especially suitable for monitoring if bursts of actions - – e.g., importing or updating many objects at once - – can be processed before another/the next burst starts. In this case, for example, you would see a sudden raise in the FULLTEXTINDEX and RENDITION queues and a gradual descent of them. If the queues reach 0 before the next burst the performance is sufficient, if not, there might be a performance/hardware resources problem.
...
(34) This set of metrics shows the average processing duration in milliseconds of a) all requests b) all search requests (including aggregation requests) c) all object creation requests (with and without content - file) d) all object read requests (equal to opening the object in the client) made during the entire selected time range chosen. This is only to get a rough overview of the duration relations between creating, reading and searching objects in comparison to the overall average.
(35) This visualization shows the course of the processing duration in milliseconds of a) all requests b) all search requests (including aggregation requests) c) all object creation requests (with and without content - file) d) all object read requests (equal to opening the object in the client) made during the selected time range chosen (averaged over the bucket size).
(36) This set of metrics shows the total number of requests were send to the a) core-service b) search-service and c) index-service. This is only to get an understanding of under how much load each components is under.
(37) This visualization shows the course of how many requests resulted what type of http response code where 2xx means okOK, 3xx means forwarded but okOK, 4xx means logical error (user - error) and 5xx means internal server error. The values are the sum over each bucket. This visualization is especially suitable for monitoring if, for example, after a change or update, something does not work correctly anymore. In this case you will see the 4xx and/or 5xx request count rising up and (logically) the 2xx request count descending. The Y - axis is logarithmic for once so that course of the usually very few 4xx and maybe 5xx requests can still be seen in sufficient detail.
...
(38) object (document) creations with a content file (the endpoint can also be called without actually passing a content - file, this can not cannot be distinguished here)
(39) object creations without a content - file (documents and folders)
(40) subsequent additions of a content - file to an existing object (document)
...
(43) batch updates to the index data of objects objects (only the number of batch requests. The ; the actual number of objects updated using this endpoint is not shown here.)
(44) object deletions (includes soft (to the recycle bin) and hard (actual deletion) deletions)
(45) batch deletions of objects objects (only the number of batch requests. The ; the actual number of objects deleted using this endpoint is not shown here.)
(46) retrievals of the PDF rendition of an object (document with content - file)
(47) retrievals of the original content - file of an object (document with content - file)
(48) search requests excluding aggregations
...
(50) creations of objects using the prepared state of the client (i.e., clicking on "fileFile" or "file File and open" in the prepared state of the client)
(51) executed ETL configurations (Be aware that ETL is already deprecated and will soon not be supported anymore. We recommend using Talend Open Studio.)
(52) Starts starts of workflow instances
(53) This metric set shows the count of requests sent to the top 10 - – i.e., most often called - – endpoints of the dms services -service's REST API. The value is the sum of requests made during the entire selected time range chosen. This is to get a rough estimate of which endpoints are very important to the system.
(54) This metrics set is analogous to (53) only that it is restricted to the DmsService dems-service subset of endpoints. This is to get an estimate of how many and what kind of object manipulations are done.
(55) This visualization corresponds to the "API Trace" site of the REST API website. It shows one table for each of the http response code categories (2xx, 3xx, 4xx, 5xx). In the tables, you see the endpoints that responded at least once with the corresponding http result code - – sorted by the total amount of requests sent to this endpoint (total invocations). Besides the count you can see what the minimum, maximum, total (summed up) and average response duration was so for - – for the selected time range chosen. If a table doesn't does not show up, like in this example the 5xx table, it means there were no requests that resulted in this response code.
...
For more information on how to handle kibana Kibana (manually setting filters, editing existing or creating new visualizations, etc.) please refer to the kibana Kibana documentation at at https://www.elastic.co/guide/en/kibana/8.4/index.html.