cwielenb/CNCF-Dataset huggingface dataset:
Project: Netdata (Observability and Analysis / Observability)
File: socket_statistics.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/socket_statistics.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "Socket statistics" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/Network" most_popular: False message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE COLLECTOR'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/network-wired.svg" width="150"/> Plugin: proc.plugin Module: /proc/net/sockstat <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This integration provides socket statistics. This collector is supported on all platforms. This collector supports collecting metrics from multiple instances of this integration, including remote instances. This integration doesn't support auto-detection. The default configuration for this integration does not impose any limits on data collection. The default configuration for this integration is not expected to impose a significant performance impact on the system. Metrics grouped by scope. The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | ip.sockstat_sockets | used | sockets | | ipv4.sockstattcpsockets | alloc, orphan, inuse, timewait | sockets | | ipv4.sockstattcpmem | mem | KiB | | ipv4.sockstatudpsockets | inuse | sockets | | ipv4.sockstatudpmem | mem | sockets | | ipv4.sockstatudplitesockets | inuse | sockets | | ipv4.sockstatrawsockets | inuse | sockets | | ipv4.sockstatfragsockets | inuse | fragments | | ipv4.sockstatfragmem | mem | KiB | The following alerts are available: | Alert name | On metric | Description | |:|:-|:| | | ipv4.sockstattcpsockets | orphan IPv4 TCP sockets utilization | | | ipv4.sockstattcpmem | TCP memory utilization | No action required. There is no configuration file. There are no configuration options. There are no configuration examples.
Project: Grafana Loki (Observability and Analysis / Observability)
File: grafana.md

title: Visualize log data menuTitle: Visualize description: Visualize your log data with Grafana aliases: ../getting-started/grafana/ ../operations/grafana/ weight: 725 keywords: visualize grafana dashboards Modern Grafana versions after 6.3 have built-in support for Grafana Loki and . Log into your Grafana instance. If this is your first time running Grafana, the username and password are both defaulted to `admin`. In Grafana, go to `Connections` > `Data Sources` via the cog icon on the left sidebar. Click the big <kbd>+ Add a new data source</kbd> button. Search for, or choose Loki from the list. The http URL field should be the address of your Loki server. For example, when running locally or with Docker using port mapping, the address is likely `http://localhost:3100`. When running with docker-compose or Kubernetes, the address is likely `http://loki:3100`.\ When running Grafana (with Docker) and trying to connect to a locally built Loki instance, the address (for the URL field) is:\ On Mac: `docker.for.mac.localhost` \ On Windows: `docker.for.win.localhost` To see the logs, click <kbd>Explore</kbd> on the sidebar, select the Loki data source in the top-left dropdown, and then choose a log stream using the <kbd>Log labels</kbd> button. Learn more about querying by reading about Loki's query language . If you would like to see an example of this live, you can try Read more about Grafana's Explore feature in the and on how to search and filter for logs with Loki. Because Loki can be used as a built-in data source above, we can use LogQL queries based on that datasource to build complex visualizations that persist on Grafana dashboards. {{< docs/play title="Loki Example Grafana Dashboard" url="https://play.grafana.org/d/T512JVH7z/" >}} Read more about how to build Grafana Dashboards in To configure Loki as a data source via provisioning, see [Configuring Grafana via Provisioning](http://docs.grafana.org/features/datasources/loki/#configure-the-datasource-with-provisioning). Set the URL in the provisioning.
Project: Kuberhealthy (Observability and Analysis / Observability)
File: RELEASE.md

To release a new version of Kuberhealthy: Ensure that all issues in the release milestone are completed Verify that the master branch has all the latest changes that have been tested and verified After any running `Build and Push kuberhealthy Unstable` action is completed, tag a release candidate from the build done in master as unstable ``` docker pull kuberhealthy/kuberhealthy:unstable docker tag kuberhealthy/kuberhealthy:unstable kuberhealthy/kuberhealthy:v[version]-rc.1 docker push kuberhealthy/kuberhealthy:v[version]-rc.1 ``` If the release looks good, tag it with the final new upcoming version along with the `latest` tag and push it to docker hub: ``` docker pull kuberhealthy/kuberhealthy:v[version]-rc.1 docker tag kuberhealthy/kuberhealthy:v[version]-rc.1 kuberhealthy/kuberhealthy:v[version] docker push kuberhealthy/kuberhealthy:v[version] docker tag kuberhealthy/kuberhealthy:v[version] kuberhealthy/kuberhealthy:latest docker push kuberhealthy/kuberhealthy:latest ``` Create a `Release` draft on GitHub named with the release version (such as `v2.3.4`) Write up and publish release notes, giving an update / latest changes from the last release: new Kuberhealthy Checks (if any), new Features, and Bug Fixes Tag the issue and pr as well as the contributor to the release notes Merge auto-generated `Flat Spec File Regeneration ` and `Package and Index for Helm Repo` PRs Close the GitHub milestone and create a new milestone version for the next release 1 Celebrate!
Project: Vector (Observability and Analysis / Observability)
File: 2021-08-24-vector-aggregator.md

date: "2021-08-24" title: "Moving the aggregator Helm chart to public beta" description: "The Vector aggregator Helm chart is now publicly available" authors: ["spencergilbert"] pr_numbers: [8801] release: "0.16.0" hideonrelease_notes: false badges: type: "announcement" platforms: ["helm", "kubernetes"] We're happy to announce that our is now in public beta! This chart has undergone rigorous testing with our internal design partners and is now ready for wider community feedback. Follow the . Checkout the for a full list of options. Hop in our for help. When Vector is deployed as an , it is used to transform and ship data collected by other agents. The core benefit of having distinct agents and aggregators is that you can have a separation of concerns within an observability data processing pipeline. Agents can become much thinner, in some cases acting as pure pipes that collect from a source and ship downstream to aggregators, while aggregators perform the thicker work of ensuring that the data is scrubbed of sensitive information, properly formatted for downstream consumers, sampled to reduce volume, and more. This is especially useful when inserting Vector into existing setups. The `vector-aggregator` chart deploys Vector as a , with the option of installing a HAProxy Deployment for load balancing across multiple aggregators. Instructions on how setup and install the `vector-aggregator` chart can be found . Our next steps involve improving the out-of-the-box experience and reducing the configuration required to aggregate events from a number of common sources. We are also looking to provide a better experience integrating load balancing across multiple aggregators with additional work on the bundled HAProxy deployment.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: traceql-search.md

description: Learn how to create TraceQL queries in Grafana using Explore > Search. keywords: grafana tempo traces queries menuTitle: Search traces title: Search traces using TraceQL query builder Inspired by PromQL and LogQL, TraceQL is a query language designed for selecting traces. TraceQL provides a method for formulating precise queries so you can zoom in to the data you need. Query results are returned faster because the queries limit what is searched. To learn more about how to query by TraceQL, refer to the . The TraceQL query builder, located on the Explore > Query type > Search in Grafana, provides drop-downs and text fields to help you write a query. This feature is automatically available in Grafana 10 (and newer) and Grafana Cloud. To enable the TraceQL query builder in self-hosted Grafana through version 10.1, . {{< docs/shared source="grafana" lookup="datasources/tempo-search-traceql.md" leveloffset="+1" version="<GRAFANA_VERSION>" >}}
Project: Sensu (Observability and Analysis / Observability)
File: feature_template.md

name: 'Feature request' about: 'Suggest new features and changes' <! Provide a general summary of the feature request in the Title above --> <! If you're looking for help, please see https://sensu.io/support/ for resources > <! Tell us how we could improve your experience --> <! Not obligatory, but ideas as to the implementation of the addition or change --> <! What are you trying to accomplish? --> <! Providing context (e.g. links to configuration settings, stack strace or log data) helps us come up with a solution that is most useful in the real world -->
Project: HertzBeat (Observability and Analysis / Observability)
File: extend-snmp.md

id: extend-snmp title: SNMP Protocol Custom Monitoring sidebar_label: SNMP Protocol Custom Monitoring From , you are familiar with how to customize types, Metrics, protocols, etc. Here we will introduce in detail how to use SNMP to customize Metric monitoring. JMX protocol custom monitoring allows us to easily monitor Metrics we want by config SNMP MIB OIDs. Peer Server Enable SNMP Service->HertzBeat Connect Peer Server SNMP->Query Oids Data->Metric data extraction It can be seen from the process that we define a monitoring type of Snmp protocol. We need to configure Snmp request parameters, configure which Metrics to obtain, and configure oids. By configuring the metrics `field`, `aliasFields`, and `oids` under the `snmp` protocol of the monitoring template YML to capture the data specified by the peer and parse the mapping. HertzBeat Dashboard -> Monitoring Templates -> New Template -> Config Monitoring Template Yml -> Save and Apply -> Add A Monitoring with The New Monitoring Type Configuration usages of the monitoring templates yml are detailed below. We define all monitoring collection types (mysql,jvm,k8s) as yml monitoring templates, and users can import these templates to support corresponding types of monitoring. Monitoring template is used to define the name of monitoring type(international), request parameter mapping, index information, collection protocol configuration information, etc. egDefine a custom monitoring type `app` named `example_windows` which use the SNMP protocol to collect data. ```yaml category: os app: windows name: zh-CN: Windows en-US: OS Windows params: field: host name: zh-CN: Host en-US: Host type: host required: true field: port name: zh-CN: en-US: Port type: number range: '[0,65535]' required: true defaultValue: 161 field: version name: zh-CN: SNMP en-US: SNMP Version type: radio required: true options: label: SNMPv1 value: 0 label: SNMPv2c value: 1 field: community name: zh-CN: SNMP en-US: SNMP Community type: text limit: 100 required: true placeholder: 'Snmp community for v1 v2c' field: timeout name: zh-CN: (ms) en-US: Timeout(ms) type: number range: '[0,100000]' required: false hide: true defaultValue: 6000 metrics: name: system priority: 0 fields: field: name type: 1 field: descr type: 1 field: uptime type: 1 field: numUsers type: 0 field: services type: 0 field: processes type: 0 field: responseTime type: 0 unit: ms field: location type: 1 protocol: snmp snmp: host: ^^host^^ port: ^^port^^ timeout: ^^timeout^^ community: ^^community^^ version: ^^version^^ operation: get oids: name: 1.3.6.1.2.1.1.5.0 descr: 1.3.6.1.2.1.1.1.0 uptime: 1.3.6.1.2.1.25.1.1.0 numUsers: 1.3.6.1.2.1.25.1.5.0 services: 1.3.6.1.2.1.1.7.0 processes: 1.3.6.1.2.1.25.1.6.0 location: 1.3.6.1.2.1.1.6.0 ```
Project: Grafana Tempo (Observability and Analysis / Observability)
File: serverless_gcp.md

title: Search with Google Cloud Run description: Learn how to set up Google Cloud Run for serverless backend search. weight: 93 alias: /docs/tempo/latest/operations/backendsearch/serverlessgcp/ /docs/tempo/latest/operations/serverless_gcp/ This document walks you through setting up a Google Cloud Run for serverless backend search. For more guidance on configuration options for full backend search . Build the docker image: ```bash cd ./cmd/tempo-serverless && make build-docker-gcr ``` This will create the Docker container image to be deployed to Google Cloud Run. The docker image will be named: `tempo-serverless:latest` and `tempo-serverless:<branch>-<commit hash>`. Here is an example of that name: ```bash $ docker images | grep tempo-serverless tempo-serverless cloud-run-3be4efa 146c9d9fa63c 58 seconds ago 47.9MB tempo-serverless latest 146c9d9fa63c 58 seconds ago 47.9MB ``` Push the image to a Google Container Registry repo. Provision the Google Cloud Run service. This example uses Terraform. Configuration values should be adjusted to meet the needs of your installation. ``` locals { // this can be increased if you would like to use multiple functions count = 1 } resource "googlecloudrun_service" "run" { count = local.count name = "<service name>" location = "<appropriate region>" metadata { annotations = { "run.googleapis.com/ingress" = "internal", # this annotation can be used to limit connectivity to the service } } template { metadata { annotations = { "autoscaling.knative.dev/minScale" = "1", "autoscaling.knative.dev/maxScale" = "1000", "autoscaling.knative.dev/panic-threshold-percentage" = "110.0", # default 200.0. how aggressively to go into panic mode and start scaling heavily "autoscaling.knative.dev/window" = "10s", # default 60s. window over which to average metrics to make scaling decisions } } spec { container_concurrency = 4 containers { image = "<container image created above>" resources { limits = { cpu = "2" memory = "1Gi" } } env { name = "TEMPOGCSBUCKET_NAME" value = "<gcs bucket where tempo data is stored>" } env { name = "TEMPO_BACKEND" value = "gcs" } env { name = "TEMPOGCSHEDGEREQUESTSAT" value = "400ms" } env { name = "TEMPOGCSHEDGEREQUESTSUP_TO" value = "2" } env { name = "GOGC" value = "400" } } } } traffic { percent = 100 latest_revision = true } } ``` Add the newly-created cloud run service as external endpoints in your querier configuration. The endpoint can be retrieved from the Details tab in Google Cloud Run: ``` querier: search: external_endpoints: <trigger url from console> ```
Project: Checkmk (Observability and Analysis / Observability)
File: 15315.md

key | value | date | 2023-12-19T12:43:59+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Shortly after rebooting, solaris uptime command returned a timestamp that could not be parsed by the checkmk agent.
Project: SkyWalking (Observability and Analysis / Observability)
File: browser-http-api-protocol.md

HTTP API Protocol defines the API data format, including API request and response data format. They use the HTTP1.1 wrapper of the official . Read it for more details. Detailed information about data format can be found in . Send a performance data object in JSON format. Input: ```json { "service": "web", "serviceVersion": "v0.0.1", "pagePath": "/index.html", "redirectTime": 10, "dnsTime": 10, "ttfbTime": 10, "tcpTime": 10, "transTime": 10, "domAnalysisTime": 10, "fptTime": 10, "domReadyTime": 10, "loadPageTime": 10, "resTime": 10, "sslTime": 10, "ttlTime": 10, "firstPackTime": 10, "fmpTime": 10 } ``` OutPut: Http Status: 204 Detailed information about data format can be found in . Send an error log object list in JSON format. Input: ```json [ { "uniqueId": "55ec6178-3fb7-43ef-899c-a26944407b01", "service": "web", "serviceVersion": "v0.0.1", "pagePath": "/index.html", "category": "ajax", "message": "error", "line": 1, "col": 1, "stack": "error", "errorUrl": "/index.html" }, { "uniqueId": "55ec6178-3fb7-43ef-899c-a26944407b02", "service": "web", "serviceVersion": "v0.0.1", "pagePath": "/index.html", "category": "ajax", "message": "error", "line": 1, "col": 1, "stack": "error", "errorUrl": "/index.html" } ] ``` OutPut: Http Status: 204 Send a single error log object in JSON format. Input: ```json { "uniqueId": "55ec6178-3fb7-43ef-899c-a26944407b01", "service": "web", "serviceVersion": "v0.0.1", "pagePath": "/index.html", "category": "ajax", "message": "error", "line": 1, "col": 1, "stack": "error", "errorUrl": "/index.html" } ``` OutPut: Http Status: 204
Project: M3 (Observability and Analysis / Observability)
File: delete_cluster.md

title: "Deleting a Cluster" menuTitle: "Deleting a Cluster" weight: 14 chapter: true Delete your M3DB cluster with `kubectl`: ``` kubectl delete m3dbcluster simple-cluster ``` By default, the operator will delete the placement and namespaces associated with a cluster before the CRD resource deleted. If you do not want this behavior, set `keepEtcdDataOnDelete` to `true` on your cluster spec. Under the hood, the operator uses Kubernetes [finalizers] to ensure the cluster CRD is not deleted until the operator has had a chance to do cleanup. If for some reason the operator is unable to delete the placement and namespace for the cluster, the cluster CRD itself will be stuck in a state where it can not be deleted, due to the way finalizers work in Kubernetes. The operator might be unable to clean up the data for many reasons, for example if the M3DB cluster itself is not available to serve the APIs for cleanup or if etcd is down and cannot fulfill the deleted. To allow the CRD to be deleted, you can `kubectl edit m3dbcluster $CLUSTER` and remove the `operator.m3db.io/etcd-deletion` finalizer. For example, in the following cluster you'd remove the finalizer from `metadata.finalizers`: ```yaml apiVersion: operator.m3db.io/v1alpha1 kind: M3DBCluster metadata: ... finalizers: operator.m3db.io/etcd-deletion name: m3db-cluster ... ``` Note that if you do this, you'll have to manually remove the relevant data in etcd. For a cluster in namespace `$NS` with name `$CLUSTER`, the keys are: `_sd.placement/$NS/$CLUSTER/m3db` `_kv/$NS/$CLUSTER/m3db.node.namespaces`
Project: Loggie (Observability and Analysis / Observability)
File: ISSUE_TEMPLATE.md

Please use the following questions as a guideline to help me answer your issue/question without further inquiry. Thank you. [ ] elastic.v7 (for Elasticsearch 7.x) [ ] elastic.v6 (for Elasticsearch 6.x) [ ] elastic.v5 (for Elasticsearch 5.x) [ ] elastic.v3 (for Elasticsearch 2.x) [ ] elastic.v2 (for Elasticsearch 1.x)
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_lease.KubeLease.md

title: "Interface: KubeLease" linkTitle: "KubeLease" slug: "libk8slease.KubeLease" .KubeLease `KubeLease` `Optional` apiVersion: `string` . _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: . _ spec:
Project: Netdata (Observability and Analysis / Observability)
File: vcsa_swap_health.md

The vcsaswaphealth alert presents the swap health status of the VMware vCenter virtual machine. It is an indicator of the overall health of memory swapping on the vCenter virtual machine. First, identify the health status of the alert by checking the color and its corresponding description in the table above. Log in to the VMware vSphere Web Client: Navigate to `https://<vCenter-IP-address-or-domain-name>:<port>/vsphere-client`, where `<vCenter-IP-address-or-domain-name>` is your vCenter Server system IP or domain name, and `<port>` is the port number over which to access the vSphere Web Client. Enter the username and password, and click Login. Navigate to the vCenter virtual machine, and select the Monitor tab. Verify the swap file size by selecting the `Performance` tab, and choosing `Advanced` view. Monitor the swap usage on the virtual machine: On the `Performance` tab, look for high swap usage (`200 MB` or above). If necessary, consider increasing the swap file size. On the `Summary` tab, check for any warning or error messages related to the swap file or its usage. Check if there are any leading processes consuming an unreasonable amount of memory: If running a Linux-based virtual machine, use command-line utilities like `free`, `top`, `vmstat`, or `htop`. Look out for processes with high `%MEM` or `RES` values. If running a Windows-based virtual machine, use Task Manager or Performance Monitor to check for memory usage. Optimize the virtual machine memory settings: Verify if the virtual machine has sufficient memory allocation. Check the virtual machine's memory reservation and limit settings. Consider enabling memory ballooning for a better utilization of available memory. If the swap health status does not improve or you are unsure how to proceed, consult VMware documentation or contact VMware support for further assistance.
Project: Vector (Observability and Analysis / Observability)
File: aws_ecs_metrics.md

title: AWS ECS metrics description: > Collect Docker container stats for tasks running in and component_kind: source layout: component tags: ["aws", "ecs", "docker", "fargate", "container", "component", "source", "metrics"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Checkmk (Observability and Analysis / Observability)
File: 16632.md

key | value | date | 2024-04-15T09:44:50+00:00 version | 2.4.0b1 class | feature edition | cee component | reporting level | 1 compatible | yes When creating/editing a report users can now select the following additional options within the report property "Default time range": "First work day of this month" "Last work day of this month" "First work day of last month" "Last work day of last month" Note that these time ranges do not consider holidays.
Project: Botkube (Observability and Analysis / Observability)
File: botkube_version.md

title: botkube version Print the CLI version ``` botkube version [flags] ``` ``` botkube version botkube version -o=json botkube version -o=yaml botkube version -o=short ``` ``` -h, --help help for version -o, --output string Output format. One of: json | pretty | short | yaml (default "pretty") ``` ``` -v, --verbose int/string[=simple] Prints more verbose output. Allowed values: 0 - disable, 1 - simple, 2 - trace (default 0 - disable) ``` - Botkube CLI
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: file.md

sidebar_position: 7 The will read a local file to get your flags. :::tip Using a file to store your flags is not recommend, except if it is in a shared folder for all your services. ::: ```go linenums="1" import "github.com/thomaspoignant/go-feature-flag/retriever/file" // ... err := ffclient.Init(ffclient.Config{ PollingInterval: 3 * time.Second, Retriever: &fileretriever.Retriever{ Path: "file-example.yaml", }, }) defer ffclient.Close() ``` To configure your File retriever: | Field | Description | ||| |`Path`| location of your file on the file system.|