Skip to main content

Terms Used in Gyeeta

Some of the terms referenced in the Web UI and REST APIs are explained below.

Service​

Service refers to a TCP Listener listening on a specific IP/port of a specific host. If an application say redis listens on IP 0.0.0.0 and ports 6379 and 6380, that will count as two separate services, one for each port. Service in Gyeeta is not the same as Kubernetes Services. For service applications run in containers (docker or lxd), the network namespace is also considered so that two containers listening on same IP/port but on different network namespaces will count as two seperate services.

Subsystem​

Gyeeta metric categories are referred to as subsystem. Main subsystems include : Service State, Process State, Network Inbound and Outbound, Host State, Cluster State. Subsystems are analogous to database tables.

Grouped Process​

Gyeeta groups parent and child processes which run the same executable as a Grouped Process. All the processes within a Grouped Process have the same name and are created from the same binary and have the same parent/grandparent process. If after a parent creates a child process and then the child executes a new binary, the child will not be grouped along with the parent as it becomes a new Grouped Process. Grouped Processes can contain a minimum of 1 process.

Grouped Process Name​

A Grouped Process is named from the executable binary used to spawn the process. For example, say postgres binary has been run by the shell. The newly created Process Group will have its name as postgres. The Process Name is truncated to max 15 bytes. For interpreted applications such as java, python, node or ruby, all processes will have the name set as the interpreter used such as java or node. This makes it difficult to figure which exact application is being referenced. In such cases, users should check the process cmdline field within the resultset returned by Gyeeta to figure the actual application.

Service Name​

Gyeeta assigns each service a Service Name based on the Grouped Process Name of the process which started the service listener. The Service Name is truncated to max 15 bytes. For interpreted applications such as java, python, node or ruby, the services will have the name set as the interpreter used such as java or node. This makes it difficult to figure which exact service is being referenced. In such cases, users can check either of the Listener IP/Port, cmdline, tag, domain fields within the resultset returned by Gyeeta to figure the actual service.

Cluster Name​

Each Monitored Host is assumed to be a part of a related Host Group or a cluster, say dev, test1, prod, etc. While configuring theHost Monitor agent partha, users need to configure the appropriate Cluster Name. In Kubernetes terminology, the Cluster Name could be the current-cluster in kubectl config. The cluster name should be set as the same for related hosts which will enable in quicker filtering and identifying Service Cluster Groups.

QPS (Queries/sec)​

QPS refers to Queries per sec. A query is a request and response pair with a request being the incoming data to a Service and response being the outbound data. Gyeeta will monitor the actual QPS and Response Times of all services without any sampling.

Response Time (Latency)​

Response Time also referred to as Latency, indicates the time in msec that a Service takes to respond to a prior request sent by a Client. If a response from the Service is spread out (staggered) with some data being sent initially followed later by some other data, Gyeeta will only report the time taken by the service to send the initial data. In other words, Response Time in Gyeeta refers to the time taken by the service to start sending the response data.

CPU Delay​

CPU Delay refers to the time in msec a Grouped Process had to wait for a CPU to become available while active. Non-zero values give an indication of either CPU contention or CPU Resource Limits such as Kubernetes Limits.

IO Delay​

IO Delay refers to the time in msec a Grouped Process had to wait for the completion of a prior initiated synchronous block I/O. Non-zero values may indicate a Disk IO contention or a slow Block device.

Memory Delay​

Memory Delay refers to the time in msec a Grouped Process had to wait for a Virtual Memory operation to complete. Non-zero values may indicate Memory contention due to Page Swapping or Memory Reclaiming.

CPU Throttled (CPU Limited) Process​

Gyeeta flags a Grouped Process as CPU Throttled if processes within the group belong to a cgroup with limits set for CPU utilization such as Kubernetes limits.

Memory Limited Process​

Gyeeta flags a Grouped Process as Memory Limited if processes within the group belong to a cgroup with limits set for max Resident Memory utilization such as Kubernetes limits.

cgroup Memory Util %​

For Grouped Processes which are Memory Limited, this metric shows the current Memory cgroup Utilization percent. If the percent is approaching 100%, an Out of Memory OOM event may be trigered.

Active Conns (Connections)​

Active Connections refer to the connections which have inbound or outbound traffic active during the time period requested.

Upstream Service​

If a service connects to another service as a TCP client, the service connected to will be the Upstream Service.

Downstream Service/Application​

If a service/process connects to another service as a TCP client, the client service/process will be the Downstream Service/Application.

Aggregation​

Aggregation refers to operations on a set of individual records to form a reduced (aggregated) resultset. In Gyeeta, Aggregation operates on a time duration of 1 min or more. Aggregation intervals define the step size used for aggregation operations on the resultset. The main Aggregation Operations include : average, minimum, maximum, sum, percentile, count.

Virtual IP / Virtual Port​

Virtual IP/Port refers to an IP/Port that client applications will connect to and these clients will then be routed to one or more actual service instances. In Kubernetes terminology, these refer to Service IP/Ports. In most cases, the Virtual IP/Port will act as a proxy using NAT or in-kernel proxying.

Service Group​

A Service Group in Gyeeta refers to 2 or more services which are assumed by Gyeeta to be related and part of a possible Cluster. For example, a set of nginx instances listening on same Virtual IP/Port would be considered as a Service Group. Gyeeta does not connect to any Cluster Orchestrator (such as Kubernetes API server) and instead tries to itself identify Service Groups based on a few conditions such as two services being in the same Cluster, having same name and interconnected to each other or having same Virtual IP/Ports.

Virtual IP Service Group​

A Virtual IP Service Group in Gyeeta refers to 2 or more services which have the same executable name and same Cluster Names and which have the same Virtual IP and Virtual Port. Gyeeta assumes these services act as a Service Group.

Interconnected Service Group​

An Interconnected Service Group in Gyeeta refers to 2 or more services which have the same executable name and same Cluster Names and which are connected to one another in a mesh style network. Gyeeta assumes these services act as a Service Group.