So application logs include, for example, Cloud Controller staging logs when an application is pushed, or Gorouter logs reporting HTTP requests for an application. Application logs within PAS cover both log output from the application code itself, written to stdout or stderr, as well as logs produced by processes running on PAS components that are involved in running and managing the application. Application logsĪpplication logs are messages tagged as HttpStartStop or LogMessage. ![]() Note, however, that not all add-on services emit metrics. Component metrics also include any metrics sent to Loggregator by add-on services deployed on your cluster, such as Redis or Pivotal Healthwatch. So these types of messages would include, for example, data on Gorouter latency, or disk usage for your component VMs. They cover any of the key metrics covered in part two, including BOSH VM system metrics. They are messages tagged as ValueMetric, CounterEvent, or ContainerMetric types. Origin:"rep" eventType:ContainerMetric timestamp:1538745163443777235 deployment:"cf" job:"compute" index:"542240fa-abc2-4961-99ed-682977b62b9e" ip:"10.0.4.38" tags: containerMetric:Ĭomponent metrics are, naturally enough, metrics that are emitted by the various Pivotal Platform components. You can see the dropsonde event type ( ContainerMetric) as well as other metadata such as a timestamp and the name of the PAS component that emitted it (the cell Rep): The following is an example of a Firehose message from the Firehose plugin. Pivotal Platform component metrics representing an incrementing counterĪpplication log messages recording the lifecycle of HTTP requestsĪpplication log messages written to stderr or stdout Metrics tracking resource utilization for the Garden containers running applications Pivotal Platform component metrics representing a value at a specific moment in time As a result, all messages coming off the Firehose are standardized into the same format but carry different metadata that allows them to be decoded, or unmarshalled, into their respective data types downstream: Loggregator event type We’ll go over using:įor the metrics and logs available from the Firehose and Log Cache, remember that PAS’s Loggregator system packages information using the dropsonde protocol, in a process called “marshalling.” Marshalling data into dropsonde involves categorizing messages into envelopes based on the event type (the type of monitoring data that a message represents), and wrapping each message with classifying metadata. In this post, we will cover ways to collect these types of data. * A syslog drain is an external service or endpoint that receives log messages in the syslog standard format. The following table breaks down these data types and how to access them: Log message type Logs and more logsīefore diving in to how to collect them, it’s important to understand the different types of monitoring data that are available from a Pivotal Platform deployment. ![]() In this post, we’ll show you how you can view these metrics, as well as application and system logs, in order to monitor your Pivotal Platform deployment and the applications running on it. So far in this series we’ve explored Pivotal Platform’s architecture and looked at some of the most important metrics for monitoring each cluster component. Pivotal Platform is now part of VMware Tanzu following VMware’s acquisition of Pivotal in late 2019. This post is part three of a four-part series about monitoring the health and performance of Pivotal Platform (formerly known as Pivotal Cloud Foundry), focusing specifically on the Pivotal Application Service runtime.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |