cwielenb/CNCF-Dataset huggingface dataset:
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: developer-guide.md

title: "" weight: 11 description: " Crane " First, please make sure you've got a working and . Please referring to Clone the repository, ```bash mkdir -p $GOPATH/src/github.com/gocrane/ cd $GOPATH/src/github.com/gocrane/ git clone https://github.com/gocrane/crane.git cd crane ``` Run ```bash make all ``` to build binaries `craned`, `crane-agent` and `metric-adapter` for `linux/amd64`. Also you could specify other platforms when building, such as, ```bash PLATFORMS=linux/arm64,darwin/amd64 make crane-agent ``` All the built binaries will be placed at `$GOPATH/src/github.com/gocrane/crane/bin` folder. You can also build docker images. Here `docker buildx` is used to help build multi-arch container images. If you're running MacOS, please install and then check the builder, ```bash $ docker buildx ls NAME/NODE DRIVER/ENDPOINT STATUS PLATFORMS default * docker default default running linux/amd64, linux/arm64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6 ``` If you're running Linux, please refer to on the installation. !!! note For better `docker buildx` support, it is recommended to use Ubuntu Focal 20.04 (LTS), Debian Bullseye 11 and CentOS 8. And install deb/rpm package `qemu-user-static` as well, such as ```bash apt-get install qemu-user-static ``` or ```bash yum install qemu-user-static ``` ```bash make images ``` Also you could build container images for other platforms, such as `arm64`, ```bash PLATFORMS=linux/amd64,linux/arm64,linux/ppc64le make images ``` !!! note For the first make image, It takes a bit of a long time, Please be patient. When we finish the make image, in the docker desktop, we can see the image we built, and the Tag is the hash value at the time of the git commit.
Project: Grafana (Observability and Analysis / Observability)
File: intro.md

headless: true labels: products: enterprise oss title: Upgrade guide introduction We recommend that you upgrade Grafana often to stay current with the latest fixes and enhancements. Because Grafana upgrades are backward compatible, the upgrade process is straightforward, and dashboards and graphs will not change. In addition to common tasks you should complete for all versions of Grafana, there might be additional upgrade tasks to complete for a version. {{% admonition type="note" %}} There might be breaking changes in some releases. We outline these changes in the document for most releases or a separate document for releases with many breaking changes. {{% /admonition %}} For versions of Grafana prior to v9.2, we published additional information in the . When available, we list all changes with links to pull requests or issues in the . {{% admonition type="note" %}} When possible, we recommend that you test the Grafana upgrade process in a test or development environment. {{% /admonition %}}
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: detect_exceptions.md

title: Exception Detector weight: 200 generated_file: true This filter plugin consumes a log stream of JSON objects which contain single-line log messages. If a consecutive sequence of log messages form an exception stack trace, they forwarded as a single, combined JSON object. Otherwise, the input log data is forwarded as is. More info at https://github.com/GoogleCloudPlatform/fluent-plugin-detect-exceptions Note: As Tag management is not supported yet, this Plugin is mutually exclusive with ```yaml filters: detectExceptions: languages: java, python multilineflushinterval: 0.1 ``` Force line breaks between each lines when comibining exception stacks. Default: false Programming languages for which to detect exceptions. Default: `[]` Tag used in match directive. Default: `kubernetes.` Maximum number of bytes to flush (0 means no limit) Default: 0 Maximum number of lines to flush (0 means no limit) Default: 1000 The field which contains the raw message text in the input JSON data. Default: "" The interval of flushing the buffer for multiline format. Default: nil The prefix to be removed from the input tag when outputting a record. Default: kubernetes Separate log streams by this field in the input JSON data. Default: "" {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: demo-flow spec: filters: detectExceptions: multilineflushinterval: 0.1 languages: java python selectors: {} localOutputRefs: demo-output {{</ highlight >}} Fluentd config result: {{< highlight xml >}} <match kubernetes.> @type detect_exceptions @id testdetectexceptions languages ["java","python"] multilineflushinterval 0.1 removetagprefix kubernetes </match> {{</ highlight >}}
Project: Checkmk (Observability and Analysis / Observability)
File: 16423.md

key | value | date | 2024-04-16T15:15:06+00:00 version | 2.4.0b1 class | feature edition | cee component | agents level | 1 compatible | yes added support for reading `PGBINARYPATH` from `postgres.cfg`. This Werk allows setting this value with the agent bakery.
Project: Loggie (Observability and Analysis / Observability)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Vector (Observability and Analysis / Observability)
File: 2021-06-03-exec-source.md

date: "2021-06-02" title: "Generate events from an external program using the new `exec` source" description: "Introducing the new `exec` source for generating events from the output of other programs" authors: ["jszwedko"] pr_numbers: [6876] release: "0.14.0" hideonrelease_notes: false badges: type: new feature domains: ["sources"] This release includes a new `exec` source that can be used to run programs outside of Vector to generate log events by consuming the stdout and stderr output streams. This can be especially useful to consume input from sources that Vector does not yet natively support such as querying data from a Postgres database via `psql`. It is capable of either running a command on an interval or starting up a long-running command. See for more details and examples. Thanks to for this contribution.
Project: Cortex (Observability and Analysis / Observability)
File: design-patterns-and-conventions.md

title: "Design patterns and Code conventions" linkTitle: "Design patterns and Code conventions" weight: 2 slug: design-patterns-and-code-conventions Cortex adopts some design patterns and code conventions that we ask you to follow when contributing to the project. These conventions have been adopted based on the experience gained over the time and aim to enforce good coding practices and keep a consistent UX (ie. config). Cortex follows the styleguide and the section of Peter Bourgon's . Do not use global variables When registering a metric: Do not use a global variable for the metric Create and register the metric with `promauto.With(reg)` In any internal Cortex component, do not register the metric to the default prometheus registerer, but pick the registerer in input (ie. `NewComponent(reg prometheus.Registerer)`) Testing metrics: When writing using tests, test exported metrics using `testutil.GatherAndCompare()` Naming: Config file options should be lowercase with words `` (underscore) separated (ie. `memcachedclient`) CLI flags should be lowercase with words `-` (dash) separated (ie. `memcached-client`) When adding a new config option, look if a similar one already exists within the and keep the same naming (ie. `addresses` for a list of network endpoints) Documentation: A CLI flag mentioned in the documentation or changelog should be always prefixed with a single `-` (dash)
Project: Vector (Observability and Analysis / Observability)
File: 2019-12-14-kubernetes-source-alpha.md

date: "2020-03-31" title: "New Kubernetes Source (alpha)" description: "Early adopters have a new Kubernetes source to chew on" authors: ["binarylogic"] pr_numbers: [893] release: "0.6.0" hideonrelease_notes: false badges: type: "new feature" domains: ["sources"] sources: ["kubernetes"] aliases: ["/blog/kubernetes-source-alpha"] We're currently This functionality is undocumented and not yet ready for general use. However, we consider it to be at Alpha stage and suitable for adventurous early adopters to try out. <!--more--> We consider Kubernetes integration to be extremely important and we want to get this right, so we'd love to from anyone willing. The main ticket to follow is .
Project: OpenTelemetry (Observability and Analysis / Observability)
File: messaging-semconv.md

Get the messaging semantic conventions for metrics and traces to stability, and afterwards update existing messaging instrumentation across all OpenTelemetry repositories to conform with the stable conventions. Mark the messaging semantic conventions as stable. Update existing messaging instrumentation across all OpenTelemetry repositories to conform with the stable conventions. Project lead @pyohannes GC/TC sponsors @carlosalberto @trask Domain experts @alevenberg @dpauls @hongalex @joaopgrassi @lmolkova Maintainers, approvers, and engineers willing to prototype and review TBD We will keep the . Goal is to stabilize messaging semantic conventions in the first half of 2024.
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.3.10.md

Upgrade Netty from 4.1.90.Final to 4.1.91.Final , ASM 9.4 to ASM 9.5, ByteBuddy 1.14.2 to 1.14.3 () Upgrade `org.gradle.test-retry` from 1.5.1 to 1.5.2 Upgrade `org.apache.hadoop:hadoop-minicluster` from 3.3.4 to 3.3.5 OpenJDK Update (April 2023 Patch releases) Upgrade `net.minidev:json-smart` from 2.4.7 to 2.4.10 Avoid negative memory result in IndicesQueryCache stats calculation ()
Project: Netdata (Observability and Analysis / Observability)
File: ml_1min_node_ar.md

This alert is triggered when the exceeds the threshold defined in the over the most recent 1 minute window evaluated. For example, with the default of `warn: $this > 1`, this means that 1% or more of the metrics collected on the node have across the most recent 1 minute window been flagged as by Netdata. This alert is a signal that some significant percentage of metrics within your infrastructure have been flagged as anomalous accoring to the ML based anomaly detection models the Netdata agent continually trains and re-trains for each metric. This tells us something somewhere might look strange in some way. THe next step is to try drill in and see what metrics are actually driving this. Filter for the node or nodes relevant: First we need to reduce as much noise as possible by filtering for just those nodes that have the elevated node anomaly rate. Look at the `anomalydetection.anomalyrate` chart and group by `node` to see which nodes have an elevated anomaly rate. Filter for just those nodes since this will reduce any noise as much as possible. Highlight the area of interest: Highlight the timeframne of interest where you see an elevated anomaly rate. Check the anomalies tab: Check the to see an ordered list of what metrics were most anomalous in the highlighted window. Press the AR% button on Overview: You can also press the "" button on the Overview or single node dashboard to see what parts of the menu have the highest chart anomaly rates. Pressing the AR% button should add some "pills" to each menu item and if you hover over it you will see that chart within each menu section that was most anomalous during the highlighted timeframe. Use Metric Correlations: Use to see what metrics may have changed most significantly comparing before to the highlighted timeframe.
Project: Kubecost (Observability and Analysis / Continuous Optimization)
File: ROADMAP.md

The following items are considered the current OpenCost roadmap. 2023 roadmap Improved testing frameworks for backend APIs as well as frontend UI Add conformance tests to confirm implementation meets standards Deeper billing integrations with other cloud providers, e.g. Alibaba Add external cloud asset cost monitoring () More accessible & improved user interface Continued improvement of the More robust and examples. Expose carbon emission ratings Please reach us on in the channel or attend the biweekly from the to discuss OpenCost development.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_apiProxy.ApiInfo.md

title: "Interface: ApiInfo" linkTitle: "ApiInfo" slug: "libk8sapiProxy.ApiInfo" .ApiInfo Describes the API for a certain resource. group: `string` The API group. _ resource: `string` The resource name. _ version: `string` The API version.
Project: Checkmk (Observability and Analysis / Observability)
File: 16472.md

key | value | date | 2024-02-07T16:05:25+00:00 version | 2.4.0b1 class | fix edition | cre component | notifications level | 1 compatible | yes When attempting to resolve an incident which was already manually resolved, an error occured. This kind of error will now be ignored.
Project: Netdata (Observability and Analysis / Observability)
File: mysql_connections.md

The `mysql_connections` alert indicates the percentage of used client connections compared to the maximum configured connections. When you receive this alert, it means your MySQL or MariaDB server is reaching its connection limit, which could lead to performance issues or failed connections for clients. Check the current connection usage Use the following command to see the current used and total connections: ``` mysql -u root -p -e "SHOW STATUS LIKE 'maxusedconnections'; SHOW VARIABLES LIKE 'max_connections';" ``` This will display the maximum number of connections used since the server was started and the maximum allowed number of connections (`max_connections`). Monitor connections over time You can monitor the connection usage over time using the following command: ``` watch -n 1 "mysql -u root -p -e 'SHOW STATUS LIKE \"Threads_connected\";'" ``` This will update the number of currently connected threads every second. Identify connection-consuming processes If connection usage is high, check which processes or clients are using connections: ``` mysql -u root -p -e "SHOW PROCESSLIST;" ``` This gives you an overview of the currently connected clients, their states, and queries being executed. Optimize client connections Analyze the processes using connections and ensure they close their connections properly when done, utilize connection pooling, and reduce the number of connections where possible. Increase the connection limit (if necessary) If you need to increase the `max_connections` value, follow these steps: Log into MySQL from the terminal as shown in the troubleshooting section: ``` mysql -u root -p ``` Check the current limit: ``` show variables like "max_connections"; ``` Set a new limit temporarily: ``` set global max_connections = "LIMIT"; ``` Replace "LIMIT" with the desired new limit. To set the limit permanently, locate the `my.cnf` file (typically under `/etc`, but it may vary depending on your installation) and append `max_connections = LIMIT` under the `[mysqld]` section. Replace "LIMIT" with the desired new limit, then restart the MySQL/MariaDB service.
Project: Cortex (Observability and Analysis / Observability)
File: sharded_ruler.md

title: "Config for horizontally scaling the Ruler" linkTitle: "Config for horizontally scaling the Ruler" weight: 10 slug: ruler-sharding One option to scale the ruler is by scaling it horizontally. However, with multiple ruler instances running they will need to coordinate to determine which instance will evaluate which rule. Similar to the ingesters, the rulers establish a hash ring to divide up the responsibilities of evaluating rules. In order to enable sharding in the ruler the following flag needs to be set: ``` -ruler.enable-sharding=true ``` In addition the ruler requires it's own ring to be configured, for instance: ``` -ruler.ring.consul.hostname=consul.dev.svc.cluster.local:8500 ``` The only configuration that is required is to enable sharding and configure a key value store. From there the rulers will shard and handle the division of rules automatically. Unlike ingesters, rulers do not hand over responsibility: all rules are re-sharded randomly every time a ruler is added to or removed from the ring. The ruler supports six kinds of storage (configdb, azure, gcs, s3, swift, local). Most kinds of storage work with the sharded ruler configuration in an obvious way. i.e. configure all rulers to use the same backend. The local implementation reads off of the local filesystem. This is a read only backend that does not support the creation and deletion of rules through . Despite the fact that it reads the local filesystem this method can still be used in a sharded ruler configuration if the operator takes care to load the same rules to every ruler. For instance this could be accomplished by mounting a onto every ruler pod. A typical local config may look something like: ``` -ruler-storage.backend=local -ruler-storage.local.directory=/tmp/cortex/rules ``` With the above configuration the ruler would expect the following layout: ``` /tmp/cortex/rules/<tenant id>/rules1.yaml /rules2.yaml ``` Yaml files are expected to be in the .
Project: Cortex (Observability and Analysis / Observability)
File: running-cortex-on-kubernetes.md

title: "Running Cortex on Kubernetes" linkTitle: "Running Cortex on Kubernetes" weight: 3 slug: running-cortex-on-kubernetes Because Cortex is designed to run multiple instances of each component (ingester, querier, etc.), you probably want to automate the placement and shepherding of these instances. Most users choose Kubernetes to do this, but this is not mandatory. If using Kubernetes, each container should specify resource requests so that the scheduler can place them on a node with sufficient capacity. For example an ingester might request: ``` resources: requests: cpu: 4 memory: 10Gi ``` The specific values here should be adjusted based on your own experiences running Cortex - they are very dependent on rate of data arriving and other factors such as series churn. Ingesters hold hours of timeseries data in memory; you can configure Cortex to replicate the data but you should take steps to avoid losing all replicas at once: Don't run multiple ingesters on the same node. Don't run ingesters on preemptible/spot nodes. Spread out ingesters across racks / availability zones / whatever applies in your datacenters. You can ask Kubernetes to avoid running on the same node like this: ``` affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: weight: 100 podAffinityTerm: labelSelector: matchExpressions: key: name operator: In values: ingester topologyKey: "kubernetes.io/hostname" ``` Give plenty of time for an ingester to hand over or flush data to store when shutting down; for Kubernetes this looks like: ``` terminationGracePeriodSeconds: 2400 ``` Ask Kubernetes to limit rolling updates to one ingester at a time, and signal the old one to stop before the new one is ready: ``` strategy: rollingUpdate: maxSurge: 0 maxUnavailable: 1 ``` Ingesters provide an HTTP hook to signal readiness when all is well; this is valuable because it stops a rolling update at the first problem: ``` readinessProbe: httpGet: path: /ready port: 80 ``` We do not recommend configuring a liveness probe on ingesters - killing them is a last resort and should not be left to a machine.
Project: EaseAgent (Observability and Analysis / Observability)
File: spring-petclinic-demo.md

You need Java 1.8+ and easeagent: If you haven't `easeagent`, get it and set $EASEAGENTPATH: Building the demo application. ``` $ git clone https://github.com/akwei/spring-petclinic-microservices.git $ cd spring-petclinic-microservices $ mvn -DskipTests=true package ``` Run the demo application with EaseAgent. ``` $ java -jar spring-petclinic-config-server/target/spring-petclinic-config-server-2.4.2.jar $ java -jar spring-petclinic-discovery-server/target/spring-petclinic-discovery-server-2.4.2.jar $ export EASEAGENTPATH=[Replace with agent path] $ cp $EASEAGENTPATH/agent.properties $EASEAGENTPATH/vets-agent.properties $ # vi $EASEAGENTPATH/vets-agent.properties replease name to "petclinic-vets-service" $ java "-javaagent:${EASEAGENTPATH}/easeagent.jar" -Deaseagent.config.path=${EASEAGENTPATH}/vets-agent.properties -Deaseagent.server.port=9900 -jar spring-petclinic-vets-service/target/spring-petclinic-vets-service-2.4.2.jar $ export EASEAGENTPATH=[Replace with agent path] $ cp $EASEAGENTPATH/agent.properties $EASEAGENTPATH/visits-agent.properties $ vi $EASEAGENTPATH/visits-agent.properties # replease name to "petclinic-visits-service" $ java "-javaagent:${EASEAGENTPATH}/easeagent.jar" -Deaseagent.config.path=${EASEAGENTPATH}/visits-agent.properties -Deaseagent.server.port=9901 -jar spring-petclinic-visits-service/target/spring-petclinic-visits-service-2.4.2.jar $ export EASEAGENTPATH=/[Replace with agent path] $ cp $EASEAGENTPATH/agent.properties $EASEAGENTPATH/customers-agent.properties $ vi $EASEAGENTPATH/customers-agent.properties # replease name to "petclinic-customers-service" $ java "-javaagent:${EASEAGENTPATH}/easeagent.jar" -Deaseagent.config.path=${EASEAGENTPATH}/customers-agent.properties -Deaseagent.server.port=9902 -jar spring-petclinic-customers-service/target/spring-petclinic-customers-service-2.4.2.jar $ export EASEAGENTPATH=[Replace with agent path] $ cp $EASEAGENTPATH/agent.properties $EASEAGENTPATH/api-gateway-agent.properties $ vi $EASEAGENTPATH/api-gateway-agent.properties # replease name to "petclinic-api-gateway" $ java "-javaagent:${EASEAGENTPATH}/easeagent.jar" -Deaseagent.config.path=${EASEAGENTPATH}/api-gateway-agent.properties -Deaseagent.server.port=9903 -jar spring-petclinic-api-gateway/target/spring-petclinic-api-gateway-2.4.2.jar ``` Adding the following configuration in `prometheus.yml` ``` job_name: 'petclinic-vets-service' static_configs: targets: ['localhost:9900'] metrics_path: "/prometheus/metrics" job_name: 'petclinic-visits-service' static_configs: targets: ['localhost:9901'] metrics_path: "/prometheus/metrics" job_name: 'petclinic-customers-service' static_configs: targets: ['localhost:9902'] metrics_path: "/prometheus/metrics" job_name: 'petclinic-api-gateway' static_configs: targets: ['localhost:9903'] metrics_path: "/prometheus/metrics" ``` Start Prometheus ``` $ ./prometheus --config.file=prometheus.yml ``` Open Browser to visit . After visit more pages, open Prometheus manager , and search `applicationhttprequest_cnt`. You will see as following.
Project: Checkmk (Observability and Analysis / Observability)
File: 16481.md

key | value | date | 2024-02-16T10:20:50+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes The `Float` and `Percentage` valuespecs used to round to a specified and limited number of decimal places. Now all decimal precision is displayed and used.