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

When using ZMQ protocol, all communications are encrypted using symmetric-key encryption based on public/private keys from both client and server. In a Centreon context, the client is the Gorgone daemon running on the Centreon Central, the servers are the daemon running on Pollers. On both client and server, generate RSA private and public keys using centreon user. ```bash $ mkdir -p /var/spool/centreon/.gorgone/ $ chmod 700 /var/spool/centreon/.gorgone $ openssl genrsa -out /var/spool/centreon/.gorgone/privkey.pem 4092 Generating RSA private key, 4092 bit long modulus ...................................++ ...........................................................................................................................................................................++ e is 65537 (0x10001) $ openssl rsa -in /var/spool/centreon/.gorgone/privkey.pem -out /var/spool/centreon/.gorgone/pubkey.pem -pubout -outform PEM writing RSA key $ chmod 644 /var/spool/centreon/.gorgone/pubkey.pem $ chmod 600 /var/spool/centreon/.gorgone/privkey.pem ``` Copy the server public key onto the client in a specific directory (for example /var/spool/centreon/.gorgone/<target_id>) On the client, execute the following command: ```bash $ perl /usr/local/bin/gorgonekeythumbprint.pl --key-path='/var/spool/centreon/.gorgone/pubkey.pem' 2019-09-30 11:00:00 - INFO - File '/var/spool/centreon/.gorgone/pubkey.pem' JWK thumbprint: pnI6EWkiTbazjikJXRkLmjml5wvVECYtQduJUjS4QK4 ``` Make the IDs match Centreon Pollers ID to benefit from module's actions. In the /etc/centreon/config.d/20-gorgoned.yaml configuration file, add the following directives under the gorgonecore section: ```yaml gorgone: gorgonecore: id: 1 privkey: /var/spool/centreon/.gorgone/privkey.pem pubkey: /var/spool/centreon/.gorgone/pubkey.pem ``` Add the module and define the path to the dedicated configuration file. ```yaml modules: name: register package: "gorgone::modules::core::register::hooks" enable: true config_file: /etc/centreon/gorgone-targets.yml ``` Create the file /etc/centreon/gorgone-targets.yml and fill it with the following configuration: ```yaml nodes: id: 2 type: push_zmq address: 10.1.2.3 port: 5556 ``` In the /etc/centreon/config.d/20-gorgoned.yaml configuration file, add the following directives: ```yaml gorgone: gorgonecore: id: 2 externalcomtype: tcp externalcompath: "*:5556" privkey: /var/spool/centreon/.gorgone/privkey.pem pubkey: /var/spool/centreon/.gorgone/pubkey.pem authorized_clients: key: pnI6EWkiTbazjikJXRkLmjml5wvVECYtQduJUjS4QK4 ``` The authorized_clients entry allows to define the client public key thumbprint retrieved earlier.
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: v1-0.md

title: Version 1.0 release notes menuTitle: V1.0 description: Release notes for Grafana Pyroscope 1.0 weight: 900 The Pyroscope team is excited to announce the first release. Were committed to building the best continuous profiling experience in Grafana and contributing to that space along with the open-source community. From the first release you can expect: Pyroscope is a horizontally-scalable, highly-available, multi-tenant continuous profiling aggregation system with similar architecture to Grafana Mimir, Grafana Loki, and Grafana Tempo. Easy to get started with guides covering Helm, Tanka, and docker-compose installations. A fully integrated data source in Grafana to correlate your continuous profiling data with other observability signals using Grafana Explore and dashboards. The native flame graph panel visualization can also be used by other profiling data sources. For more details check out the and the .
Project: Netdata (Observability and Analysis / Observability)
File: redis_bgsave_broken.md

This alert is triggered when the Redis server fails to save the RDB snapshot to disk. This can indicate issues with the disk, the Redis server itself, or other factors affecting the save operation. Check Redis logs: Inspect the Redis logs to identify any error messages or issues related to the failed RDB save operation. You can typically find the logs in `/var/log/redis/redis-server.log`. Verify disk space: Ensure that your server has enough disk space available for the RDB snapshot. Insufficient disk space can cause the save operation to fail. Check disk health: Use disk health monitoring tools like `smartctl` to inspect the health of the disk where the RDB snapshot is being saved. Review Redis configuration: Check your Redis server's configuration file (`redis.conf`) for any misconfigurations or settings that may be causing the issue. Ensure that the `dir` and `dbfilename` options are correctly set. Monitor server resources: Monitor your server's resources, such as CPU and RAM usage, to ensure that they are not causing issues with the save operation. Restart Redis: If the issue persists, consider restarting the Redis server to clear any temporary issues or stuck processes.
Project: Elastic (Observability and Analysis / Observability)
File: to_boolean.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts an input value to a boolean value. A string value of true will be case-insensitive converted to the Boolean true. For anything else, including the empty string, the function will return false. The numerical value of 0 will be converted to false, anything else will be converted to true. ``` ROW str = ["true", "TRuE", "false", "", "yes", "1"] | EVAL bool = TO_BOOLEAN(str) ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16523.md

key | value | date | 2024-02-20T06:46:32+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no When deleting an ec event via the REST-API, only the 'by_id' option leaves the event selection ambiguous, while the options 'params' or 'query' already have the ability to pinpoint the event requested. Therefore, the site_id should is not required in these cases.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-plugin_delete.md

category: Plugin apiurl: '/api/v1/plugin/#{plugin_id}' title: "Delete Plugin" type: 'DELETE' sample_doc: 'plugin.html' layout: default Required ex. /api/v1/plugin/1501 ```Status: 200``` ```{"message":"plugin:1501 is deleted"}```
Project: Vector (Observability and Analysis / Observability)
File: 2020-02-14-global-log-schema.md

date: "2020-04-19" title: "Introducing Vector's Global Log Schema" description: "Set defaults for Vector's common log key names" authors: ["binarylogic"] pr_numbers: [1769, 1795] release: "0.8.0" hideonrelease_notes: false badges: type: "new feature" domains: ["config"] Vector does not require a rigid schema for it's [`log` events][docs.data-model.log]. You are welcome to use any field names you like, such as the `timestamp`, `message`, and `host`. Until recently, the default names of these fields were not easily customizable. You either had to set these names within the itself, or rename these fields using the . While this works, it's cumbersome and is not obvious to anyone reading your Vector configuration file. Enter Vector's new [global log schema][docs.global-options#log_schema]. These new options allow you to change the default names for the , , , and more: ```toml title="vector.toml" [log_schema] host_key = "host" # default message_key = "message" # default timestamp_key = "timestamp" # default ``` Why is this useful? Many Vector users already have a schema in-place and this makes it easy for Vector to adopt that schema. Components often times need to coordinate. For example, the is used in a variety of to ensure that Vector's internal "host" field is mapped to the downstream service's "host" field.
Project: Netdata (Observability and Analysis / Observability)
File: windows_inbound_packets_errors.md

This alert informs you about the number of `inbound errors` on the network interface of your Windows machine within the last 10 minutes. If you receive this alert, it indicates that there might be issues with your network connection or hardware. Inbound errors refer to problems that occur when packets are coming into the network interface of your machine from external sources. These errors might occur due to various reasons such as packet loss during transmission, hardware problems in the network interface card (NIC), or incorrect network configurations. To troubleshoot this alert, you can perform the following steps: Check the network connection Ensure that the network connection is stable and the cables (if any) are properly connected. If you're using a wireless connection, verify that the signal strength is good and that there are no known Wi-Fi issues in your area. Verify network configurations Go through your network configurations and ensure that they are properly set. Some common issues include incorrect IP addresses, subnet masks or gateways. Open the Network Connections window (press Windows key + R, type `ncpa.cpl` and click OK), then right-click your network adapter, select `Properties`, and recheck your configurations. Inspect the hardware Check if the NIC experiences any physical issues or if it gets overheated. If you suspect a hardware problem, consider replacing the NIC or connecting to a different network interface to isolate the issue. Monitor the network for any anomalies You can use native Windows tools like `Performance Monitor` or `Resource Monitor` to keep an eye on network performance and packet errors. Open the respective tools by searching in the Start Menu. Review Event Viewer logs Look for any network-related errors logged in the `Event Viewer`. Press Windows key + X, select Event Viewer, and navigate to `Windows Logs` > `System`. Filter the logs by choosing the `Network Profile` event source and review the error messages. Update NIC drivers Sometimes, outdated or faulty NIC drivers might cause inbound packet errors. Ensure that you've installed the latest drivers for your NIC. Visit the manufacturer's website to download and install the most recent drivers compatible with your Windows operating system.
Project: Tracetest (Observability and Analysis / Observability)
File: tracetest_completion.md

Generate the autocompletion script for the specified shell Generate the autocompletion script for tracetest for the specified shell. See each sub-command's help for details on how to use the generated script. ``` -h, --help help for completion ``` ``` -c, --config string config file will be used by the CLI (default "config.yml") -o, --output string output format [pretty|json|yaml] -s, --server-url string server url -v, --verbose display debug information ``` - CLI to configure, install and execute tests on a Tracetest server - Generate the autocompletion script for bash - Generate the autocompletion script for fish - Generate the autocompletion script for powershell - Generate the autocompletion script for zsh
Project: Netdata (Observability and Analysis / Observability)
File: apcupsd_10min_ups_load.md

This alert is related to your APC uninterruptible power supply (UPS) device. If you receive this alert, it means that your UPS is experiencing high load, which could result in it entering bypass mode or shutdown to protect the device. The alert is triggered in a warning state when the average UPS load is between 70-80% and in a critical state when it is between 85-95%. Follow these steps to address the high load on your UPS device: Identify devices connected to the UPS: Make a list of all the devices connected to the UPS. This list could include computers, servers, routers, and other essential equipment. Assess the importance of each device: Prioritize the devices connected to the UPS based on their importance to your network infrastructure. Determine which devices are mission-critical and which ones can be temporarily disconnected without causing significant disruptions. Disconnect non-critical devices: Once you have assessed the importance of the connected devices, disconnect any non-critical devices to reduce the load on the UPS. This action will help ensure that the mission-critical devices continue to receive power during a utility failure. Consider additional UPS capacity: If you frequently receive this alert or are unable to disconnect enough devices to reduce the load on the UPS, consider adding additional UPS capacity to your infrastructure. This additional capacity could come in the form of additional UPS units or a larger UPS with a higher output capacity. Monitor the UPS load: After disconnecting non-critical devices or adding additional UPS capacity, continue monitoring the UPS load using the Netdata Agent to ensure the load stays within acceptable limits. If the alert persists, you may need to reevaluate your infrastructure and device connections.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-dashboard_screen_gets_by_pid.md

category: DashboardScreen apiurl: '/api/v1/dashboard/screens/pid/:screen_pid' title: 'Gets DashboardScreens by pid' type: 'GET' sample_doc: 'dashboard.html' layout: default Required ```Status: 200``` ``` [ { "id": 952, "name": "a1", "pid": 0 }, { "id": 961, "name": "laiwei-sceen1", "pid": 0 } ] ``` For errors responses, see the .
Project: Weave Scope (Observability and Analysis / Observability)
File: CONTRIBUTING.md

Welcome to Kubernetes. We are excited about the prospect of you joining our ! The Kubernetes community abides by the CNCF . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. We have full documentation on how to get started contributing here: <! If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers - We have a diverse set of mentorship programs available that are always looking for volunteers! <! Custom Information - if you're copying this template for the first time you can add custom content here, for example: - Replace `kubernetes-users` with your slack channel string, this will send users directly to your channel. -->
Project: Vector (Observability and Analysis / Observability)
File: prometheus_exporter.md

title: Prometheus Exporter description: Output metric events to a running on the host component_kind: sink layout: component tags: ["prometheus", "exporter", "component", "sink", "metrics"] aliases: ["/docs/reference/sinks/prometheus"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Chaos Mesh (Observability and Analysis / Chaos Engineering)
File: README.md

Chaosctl is a tool (currently) used to print debug info. Maintainers would make use of it to better provide their suggestions for issues. ```shell cd $CHAOSMESH_DIR make chaosctl ./bin/chaosctl --help # to see if build succeeds. ``` Chaoctl supports shell autocompletion, which could save you some typing. Do `./bin/chaosctl completion -h` for detail. Debug `chaoctl debug` is used to print debug info of certain chaos. Currently, it supports networkchaos, stresschaos and iochaos. ```shell ./bin/chaosctl debug networkchaos ./bin/chaosctl debug networkchaos CHAOSNAME ./bin/chaosctl debug networkchaos -n NAMESPACE ``` Logs `chaoctl logs` is used to easily print log from all chaos-mesh components, including controller-manager, chaos-daemon and chaos-dashboard. ```shell ./bin/chaosctl logs ./bin/chaosctl logs -t 100 -n NODENAME ``` An example output structure of `debug` would be like: ``` CHAOSNAME PODNAME (which the chaos would take effect on) DEBUG_INFO PODNAME DEBUG_INFO ``` The `DEBUG_INFO` of each supported chaos would be: NetworkChaos: `ipset list` of chaos daemon `tc qdisc list` `iptables list` podnetworkchaos spec StressChaos: `ps` of target pod `cat /proc/${PID}/cgroup` of each process `cat /proc/${stress-ng_PID}/cgroup` the actual `cpu`/`memory` limit, compared with the set value IOChaos: `cat /proc/mounts` of target pod `ls -l /proc/${PID}/fd`
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_persistentVolume.KubePersistentVolume.md

title: "Interface: KubePersistentVolume" linkTitle: "KubePersistentVolume" slug: "libk8spersistentVolume.KubePersistentVolume" .KubePersistentVolume `KubePersistentVolume` `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: `Object` | Name | Type | | : | : | | `capacity` | { `storage`: `string` } | | `capacity.storage` | `string` | _ status: `Object` | Name | Type | | : | : | | `message` | `string` | | `phase` | `string` | | `reason` | `string` |
Project: HertzBeat (Observability and Analysis / Observability)
File: alert_console.md

id: alert_console title: Custom console address in alarm template sidebar_label: Console address in alarm template After the threshold is triggered, send the alarm information. When you notify through DingDing / enterprise Wechat / FeiShu robot or email, the alarm content has a detailed link to log in to the console. In our startup configuration file application.yml, find the following configuration ```yml alerter: console-url: #Here is our custom console address ``` The default value is the official console address of HertzBeat.
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.Registry.md

title: "Class: Registry" linkTitle: "Registry" slug: "plugin_registry.Registry" .Registry new Registry() registerAppBarAction(`actionName`, `actionFunc`): `void` `deprecated` Registry.registerAppBarAction is deprecated. Please use registerAppBarAction. | Name | Type | | : | : | | `actionName` | `string` | | `actionFunc` | (...`args`: `any`[]) => ``null`` \| `Element` | `void` _ registerAppLogo(`logo`): `void` `deprecated` Registry.registerAppLogo is deprecated. Please use registerAppLogo. | Name | Type | | : | : | | `logo` | | `void` _ registerClusterChooserComponent(`component`): `void` `deprecated` Registry.registerClusterChooserComponent is deprecated. Please use registerClusterChooser. | Name | Type | | : | : | | `component` | ``null`` \| `ComponentType`<\> | `void` _ registerDetailsViewHeaderAction(`actionName`, `actionFunc`): `void` `deprecated` Registry.registerDetailsViewHeaderAction is deprecated. Please use registerDetailsViewHeaderAction. | Name | Type | | : | : | | `actionName` | `string` | | `actionFunc` | `HeaderActionType` | `void` _ registerDetailsViewSection(`sectionName`, `sectionFunc`): `void` `deprecated` Registry.registerDetailsViewSection is deprecated. Please use registerDetailsViewSection. ```tsx register.registerDetailsViewSection('biolatency', resource => { if (resource?.kind === 'Node') { return { title: 'Block I/O Latency', component: () => <CustomComponent />, }; } return null; }); ``` | Name | Type | | : | : | | `sectionName` | `string` | | `sectionFunc` | (`props`: { `resource`: `any` }) => ``null`` \| | `void` _ registerRoute(`routeSpec`): `void` `deprecated` Registry.registerRoute is deprecated. Please use registerRoute. | Name | Type | | : | : | | `routeSpec` | | `void` _ registerSidebarItem(`parentName`, `itemName`, `itemLabel`, `url`, `opts?`): `void` `deprecated` Registry.registerSidebarItem is deprecated. Please use registerSidebarItem. | Name | Type | | : | : | | `parentName` | ``null`` \| `string` | | `itemName` | `string` | | `itemLabel` | `string` | | `url` | `string` | | `opts` | `Pick`<, ``"sidebar"`` \| ``"icon"`` \| ``"useClusterURL"``\> | `void`
Project: Netdata (Observability and Analysis / Observability)
File: apcupsd_last_collected_secs.md

This alert is related to your American Power Conversion (APC) uninterruptible power supply (UPS) device. The Netdata Agent monitors the number of seconds since the last successful data collection by querying the `apcaccess` tool. If you receive this alert, it means that no data collection has taken place for some time, which might indicate a problem with the APC UPS device or connection. Verify the `apcaccess` tool is installed and functioning properly ``` $ apcaccess status ``` This command should provide you with a status display of the UPS. If the command is not found, you may need to install the `apcaccess` tool. Check the APC UPS daemon a. Check the status of the APC UPS daemon ``` $ systemctl status apcupsd ``` b. Check for obvious and common errors, such as wrong device path, incorrect permissions, or configuration issues in `/etc/apcupsd/apcupsd.conf`. c. If needed, restart the APC UPS daemon ``` $ systemctl restart apcupsd ``` Inspect system logs Check the system logs for any error messages related to APC UPS or `apcupsd`, which might give more insights into the issue. Verify UPS Connection Ensure that the UPS device is properly connected to your server, both physically (USB/Serial) and in the configuration file (`/etc/apcupsd/apcupsd.conf`). Update Netdata configuration If the issue is still not resolved, you can try updating the Netdata configuration file for the `apcupsdlastcollected_secs` collector. Check your UPS device If all previous steps have been completed and the issue persists, your UPS device might be faulty. Consider contacting the manufacturer for support or replace the device with a known-good unit.
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: socket-collector.md

title: Gadget socket-collector The socket-collector gadget gathers information about TCP and UDP sockets. ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: socket-collector namespace: gadget spec: node: my-node gadget: socket-collector filter: namespace: default podname: mypod runMode: Manual outputMode: Status parameters: proto: all # all, udp and tcp are allowed ``` Create a snapshot of the currently open TCP and UDP sockets. Once taken, the snapshot is not updated automatically. However one can call the collect operation again at any time to update the snapshot. ```bash $ kubectl annotate -n gadget trace/socket-collector \ gadget.kinvolk.io/operation=collect ``` Status