CoreOS Tectonic Monitoring
CoreOS Tectonic Monitoring and Performance Management
Like open source Kubernetes (K8s), commercial Kubernetes services like CoreOS Tectonic are difficult to monitor, especially when trying to understand how application performance is connected to the Kubernetes system. CoreOS Tectonic is a hosted Kubernetes cluster, which is delivered as Infrastructure As A Service (IaaS) provided by CoreOS (which was acquired by Red Hat in early 2018). Instana’s CoreOS Tectonic Monitoring, part of our broader APM and application infrastructure monitoring solutions, provides comprehensive visibility into Tectonic, the Kubernetes Engine, containers, the application infrastructure platforms running in the containers, and the applications that run across the entire system.
Instana’s automated Kubernetes Monitoring helps Operations, DevOps and Engineering teams to to optimize application performance and better automate performance management workflows by going beyond simple metrics to provide advanced monitoring features:
- Discovery of Kubernetes nodes and deployed services
- Automatic code instrumentation of deployed services (when applicable)
- Visualization of service dependency maps
- Tracing of 100% of requests across all systems and services
- Application and service health monitoring
Comprehensive monitoring of CoreOS Tectonic infrastructure requires performance visibility for the virtual hosts, running pods, containers and orchestration, as well as any applications and services deployed on the cluster.
Instana is the quickest and easiest way to monitor CoreOS Tectonic across the stack to deliver comprehensive application insights. The Instana agent automatically discovers all Kubernetes instances, deployed service technologies, deploys the necessary monitoring sensors and begins tracing applications and requests. Instana also automatically determines the health of the Tectonic cluster.
14 days, no credit card, full version
Once deployed, the Instana Agent automatically identifies all running Tectonic Kubernetes nodes – then automatically deploys and configures Instana’s Tectonic Monitoring sensor (or Kubernetes monitoring sensor) . Instana’s curated knowledge base already knows what performance metrics are relevant for collection and how to collect them. To monitor the Tectonic cluster health, additional metrics are also collected. Since Instana’s automatic configuration collects all relevant information, monitoring a hosted Kubernetes cluster couldn’t be easier.
To determine overall service health, the Instana Monitoring sensors also collect KPIs on the monitored Tectonic cluster environment to determine its health status.
With the help of Artificial Intelligence (AI) and health signatures from the curated knowledge base, Instana automatically detects issues inside the Kubernetes cluster and service incidents. Based on severity, Instana automates incident escalation and root cause identification, helping you solve issues before users are impacted.
In addition to performance and health data, Instana’s Kubernetes Monitoring sensor also collects configuration data for Kubernetes, pods and containers, allowing Instana to analyze and correlate configuration data and changes with application and service performance information.
All Kubernetes performance and configuration information is summarized in a single Monitoring Dashboard, showing all relevant information in a single place for easy problem-solving and performance optimization.
CoreOS Tectonic performance monitoring centers around service metrics and their interactions with other services or data stores. Instana automatically identifies and collects the relevant service metrics.
Instana’s Kubernetes Monitoring includes four types of data; Cluster Data, Deployment Information, Pod Measurements, Node Measurements:
Further information on the different sensor information is available in the Instana CoreOS Tectonic Management Documentation.
Cluster Data
- KPIs
- Node Count
- Pod Allocation
- CPU Request Allocation
- CPU Limit Allocation
- Memory Request Allocation
- Memory Limit Allocation
- CPU Resources
- CPU Requests
- CPU Limits
- CPU Capacity
- Memory Resources
- Memory Requests
- Memory Limits
- Memory Capacity
- Pods (running / allocated / pending)
- Pods Capacity
- Replicas (available / desired)
- Node list with KPIs
- Deployment List with KPIs
- Component Status
Node Measurements
- KPIs
- Pod Allocation
- Pod Capacity
- CPU Request Allocation
- CPU Limit Allocation
- Memory Request Allocation
- Memory Limit Allocation
- CPU Resources
- CPU Requests
- CPU Limits
- CPU Capacity
- Memory Resources
- Memory Requests
- Memory Limits
- Memory Capacity
- Conditions
- Labels
- Pod List
Pod Measurements
- KPIs
- Phase
- Restart
- CPU Requests
- CPU Limits
- Memory Requests
- Memory Limits
- Conditions
- Container List (state / restarts)
- Labels
- Conditions
- Lbels
- CPU Resources
- CPU Requests
- CPU Limits
- Memory Resources
- Memory Requests
- Memory Limits
- Pods (available / desired)
- Pods (pending / ready / unscheduled / unredy)
- Pending Phase Duration