Once you have succesfully successfully installed the yuuvis® RAD metrics-manager and opened Kibana in your browser, you can open the "metrics-dashboard" in the "Dashboards" are automatically forwarded to the Metrics-Dashboard in the Dashboard section of Kibana. Here, you will find a predefinded predefined set of visualisations visualizations of yuuvis® metrics, as well as the status of the hardware - resources of your servers. The follwing following picture shows you an examplary exemplary view of the metricsMetrics-dashboardDashboard. Below each visualisation the picture, each visualization/point of interest (POI) highlighted in the yellow boxes is explained in detaileddetail.
(1) This is the Dasboards menu section. Klick Click on it to see all available dashboards ornavigate to other dashboards, sections (Discover, Visualizations), or the management – or, if already opened before, restore the previously openend dashboard. In the latter case click on the button again to get back to the overview of all 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 visualisations visualizations shown only represent the data that corresponds to the here selected time range. If you have emtpy visualisations empty visualizations or you think some data is missing, your time range might be too small.
(3) This visualisation This is the navigation bar in the Metrics-Dashboard. 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 utilisation 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)). Be aware that 100% does not necessarily depict the maximum utilisation because metricbeat/windows treat 100% as the maximum utilisation of one CPU core. So the maximum utilisation is the number of CPU cores that the server has times 100. (You can change intervals for the green, yellow and red zones in the visualisation visualization editor, but only for the entire visualisation visualization and not for each individual tacho.)
(45) This visualisation visualization shows the RAM utilisation 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 utilisedutilized. (You can change intervals for the green, yellow and red zones in the visualisation visualization editor.)
(56) This visualisation visualization shows the course of the CPU utilisation 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 respresents represents one bucket. The actual bucket size is the difference between two dots. The value of each dot is the average CPU utilisation utilization of the depicted server over the time that the bucket represents.
| Info | ||
|---|---|---|
| ||
Zoom in the time range: Course Line Filtering/Color: |
(67) This visualisation This visualization shows the course of the RAM utilisation utilization of each one of your server servers that runs metricbeat over the chosen selected time range. The visualisation visualization behaves analogous to to (56).
(78) This visualisation 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. (8) This visualisation
(9) This visualization shows the course of the utilization (on average over the bucket size) of each of the hard drive partitions/network shares (if using NetworkShareMonitor) of each server running metricbeat.
(10) This visualization shows the course of how many bytes (on average over the bucket size) were written on each of the hard drive partitions of each server running metricbeat. (9) This visualisation
(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 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 10 processes over all servers.
(13) This visualization shows the course of how many bytes (on average over the bucket size) were received by each network interface of each server running metricbeat.
(14) This visualization shows the course of how many bytes (on average over the bucket size) were sent by each network interface of each server running metricbeat.
(15) This visualization shows the status of each (operating system) service that is a part of the yuuvis® RAD system of each server running metricbeat.
(16) This visualization shows the percentage share of the status of each (operating system) service that is a part of the yuuvis® RAD system of each server running metricbeat.
(17) This visualization shows the course of the utilization of the JDK's heap space (on average over the bucket size) of each yuuvis® RAD component of each server running metricbeat.
(18) This indicates that the below following visualizations are all related to Elasticsearch.
(19) This visualization shows the status of each Elasticsearch cluster that is monitored by a server running metricbeat. (Usually this is only the "es-red" cluster used by yuuvis® RAD.)
(20) This visualization shows the status of each Elasticsearch index that is part of a cluster shown in (19).
(21) This visualization shows the status of each enaiored* and autocomplete* index that is part of an index shown in (20). (Other indices are used only for management purposes and should have more than one shard.)
(22) This visualization shows the course of the number of documents (on average over the bucket size) that the enaiored_* index contained. (Note: The number of documents in Elasticsearch can be higher than the number of dms objects because lists and tables are saved sub-documents in Elasticsearch that also count as documents.)
(23) This visualization shows the course of the duration (on average over the bucket size) of each garbage collection run of the Elasticsearch JDK.
(24) This indicates that the below visualizations are all related to yuuvis® RAD.
(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.
(1026) This visualisation 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.
(1127) 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.
(1228) 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.
(1329) This visualisation visualization shows the course of how many messages each queue of the messaging service contained - – on average over the bucket size. This visualisation 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 ressources resources problem.
(14) 30) This metric shows the course of how many messages (on average over the bucket size) were enqueued in each of the queues in the ActiveMQ message broker.
(31) This metric shows the course of how many messages (on average over the bucket size) were dequeued in each of the queues in the ActiveMQ message broker.
(32) This metric shows the course of how many messages (on average over the bucket size) were enqueued in each of the topics in the ActiveMQ message broker.
(33) This metric shows the course of how many messages (on average over the bucket size) were dequeued in each of the topics in the ActiveMQ message broker.
(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 comparisson comparison to the overall average.
(1535) This visualisation 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).
(1636) This set of metrics shows the total number of requests were send to the a) dmscore-service b) search-service and c) index-service. This is only to get an understanding of under how much load each components is under.
(1737) This visualisation 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 visualisation 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.
The metrics (1838) - (3252) show the total number of the following actions that succeeded (left side) and failed (right side):
(1838) object (document) creations with a conent-content file (the endpoint can also be called without actually passing a content - file, this can not cannot be distinguished here)
(1939) object creations without a content - file (documents and folders)
(2040) subsequent additions of a content - file to an existing object (document)
(2141) batch creations of objects (only the number of batch requests. The actual number of objects created using this endpoint is not shown here.)
(2242) updates to the indexdata index data of an object
(2343) batch updates to the indexdata 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.)
(2444) object deletions (includes soft (to the recycle bin) and hard (actual deletion) deletions)
(2545) 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.)
(2646) retrievals of the PDF renditon rendition of an object (document with content - file)
(2747) retrievals of the original content - file of an object (document with content - file)
(2848) search requests excluding aggregations
(2949) aggregation requests (previews the number of objects that the current search configuration would yield)
(3050) 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)
(3151) executed ETL configurations (Be aware that ETL is already deprecated and will soon not be supported anymore. We recommend using Talend Open Studio.)
(3252) Starts starts of workflow instances
(3353) This metric set shows the count of requests sent to the top 10 - – i.e., most often called - – endpoints of the dms services REST-core-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.
(3454) This metrics set is analogous to (3353) only that it is restricted to the DmsService subset of endpoints. This is to get an estimate of how many and what kind of object manipulations are done.
(3555) This visualisation 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 - orderd – 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 (manually setting filters, editing existing or creating new visualizations, etc.) please refer to the Kibana documentation at https://www.elastic.co/guide/en/kibana/8.4/index.html.