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

Promscale maintenance jobs are taking longer than expected to complete Delay in compressing chunks and executing retention policy, leading to high disk usage and data past retention period Open psql Execute the following debugging query: ```postgresql SELECT avg(chunkinterval) as avgchunkintervalnew_chunk, sum(totalsizebytes-coalesce(aftercompressionbytes,0)) AS notyetcompressed_bytes, avg(totalinterval-compressedinterval) AS avgnotyetcompressedinterval, avg(totalchunks-compressedchunks) AS avgnotyetcompressedchunks, sum(totalchunks-compressedchunks) AS totalnotyetcompressedchunks, count(*) total_metrics FROM prom_info.metric; ``` If `avgnotyetcompressedchunks > 2` then See for mitigation If `avgnotyetcompressedinterval is high AND avgnotyetcompressedchunks is small (<2)` then it indicates very big chunks. This can lead to maintenance jobs stuck on compressing this large chunk or waiting for the current chunk to stop getting new data. See for mitigation. Open Postgres logs and look for errors or deadlocks. If found, see for mitigation An immediate solution to this is manually compressing chunks by calling: `call promapi.executemaintenance();`. This will also perform retention policies. Try increasing the number of maintenance jobs by using: `SELECT promapi.configmaintenancejobs(numberjobs => X, newscheduleinterval => '30 minutes'::interval)`. The given `numberjobs` will run every `newschedule_interval` minutes (in this case, 30). Maintenance jobs are responsible for performing compression and applying retention policies. Decrease the chunk interval. Get the current interval by: Seeing the Promscale configuration file Or Running SQL: `select value from promcatalog.default where key = 'chunk_interval';` Update the interval: If you find any errors in Postgres logs or anything related to this topic, please open an issue at https://github.com/timescale/promscale/issues
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: elasticsearch_genid.md

title: ElasticSearch GenId weight: 200 generated_file: true {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: demo-flow spec: filters: elasticsearch_genid: hashidkey: gen_id selectors: {} localOutputRefs: demo-output {{</ highlight >}} Fluentd Config Result {{< highlight xml >}} <filter > @type elasticsearch_genid @id testelasticsearchgenid hashidkey gen_id </filter> {{</ highlight >}} You can specify generated hash storing key. You can specify hash algorithm. Support algorithms md5, sha1, sha256, sha512. Default: sha1 You can specify to use tag for hash generation seed. You can specify to use time for hash generation seed. You can specify keys which are record in events for hash generation seed. This parameter should be used with userecordas_seed parameter in practice. You can specify separator charactor to creating seed for hash generation. You can specify to use entire record in events for hash generation seed. You can specify to use record in events for hash generation seed. This parameter should be used with record_keys parameter in practice.
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: roadmap-2023.md

title: "Roadmap for 2023" description: "The designed roadmap items for 2023" weight: 10 Please refer the following sections for Crane release plan of 2023. Please let us know if you have urgent needs which are not presented in the plan. Optimization of Grafana & Crane Dashboard Phase 2, adding resource optimization model charts Carbon Footprint, carbon emissions display Phase 2 Support for immediately executable recommendations Utilization analysis and resource recommendation for GPU resources (no implementation of GPU sharing technology, only integration) Integration of recommendation framework with CICD platforms such as ArgoCD, Jenkins More idle resource recognition, nodes, PV, LB Cost allocation based on Project and Department application dimensions Node resource amplification
Project: OpenSearch (Observability and Analysis / Observability)
File: CODE_OF_CONDUCT.md

This code of conduct applies to all spaces provided by the OpenSource project including in code, documentation, issue trackers, mailing lists, chat channels, wikis, blogs, social media and any other communication channels used by the project. Our open source communities endeavor to: Be Inclusive: We are committed to being a community where everyone can join and contribute. This means using inclusive and welcoming language. Be Welcoming: We are committed to maintaining a safe space for everyone to be able to contribute. Be Respectful: We are committed to encouraging differing viewpoints, accepting constructive criticism and work collaboratively towards decisions that help the project grow. Disrespectful and unacceptable behavior will not be tolerated. Be Collaborative: We are committed to supporting what is best for our community and users. When we build anything for the benefit of the project, we should document the work we do and communicate to others on how this affects their work. Our Responsibility. As contributors, members, or bystanders we each individually have the responsibility to behave professionally and respectfully at all times. Disrespectful and unacceptable behaviors include, but are not limited to: The use of violent threats, abusive, discriminatory, or derogatory language; Offensive comments related to gender, gender identity and expression, sexual orientation, disability, mental illness, race, political or religious affiliation; Posting of sexually explicit or violent content; The use of sexualized language and unwelcome sexual attention or advances; Public or private harassment of any kind; Publishing private information, such as physical or electronic address, without permission; Other conduct which could reasonably be considered inappropriate in a professional setting; Advocating for or encouraging any of the above behaviors. Enforcement and Reporting Code of Conduct Issues: Instances of abusive, harassing, or otherwise unacceptable behavior may be reported. . All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances.
Project: Prometheus (Observability and Analysis / Observability)
File: http_sd.md

title: HTTP SD sort_rank: 7 Prometheus provides a generic , that enables it to discover targets over an HTTP endpoint. The HTTP Service Discovery is complimentary to the supported service discovery mechanisms, and is an alternative to . Here is a table comparing our two generic Service Discovery implementations. | Item | File SD | HTTP SD | | - | - | - | | Event Based | Yes, via inotify | No | | Update frequency | Instant, thanks to inotify | Following refresh_interval | | Format | Yaml or JSON | JSON | | Transport | Local file | HTTP/HTTPS | | Security | File-Based security | TLS, Basic auth, Authorization header, OAuth2 | If you implement an HTTP SD endpoint, here are a few requirements you should be aware of. The response is consumed as is, unmodified. On each refresh interval (default: 1 minute), Prometheus will perform a GET request to the HTTP SD endpoint. The GET request contains a `X-Prometheus-Refresh-Interval-Seconds` HTTP header with the refresh interval. The SD endpoint must answer with an HTTP 200 response, with the HTTP Header `Content-Type: application/json`. The answer must be UTF-8 formatted. If no targets should be transmitted, HTTP 200 must also be emitted, with an empty list `[]`. Target lists are unordered. Prometheus caches target lists. If an error occurs while fetching an updated targets list, Prometheus keeps using the current targets list. The targets list is not saved across restart. The `prometheussdhttpfailurestotal` counter metric tracks the number of refresh failures. The whole list of targets must be returned on every scrape. There is no support for incremental updates. A Prometheus instance does not send its hostname and it is not possible for a SD endpoint to know if the SD requests is the first one after a restart or not. The URL to the HTTP SD is not considered secret. The authentication and any API keys should be passed with the appropriate authentication mechanisms. Prometheus supports TLS authentication, basic authentication, OAuth2, and authorization headers. ```json [ { "targets": [ "<host>", ... ], "labels": { "<labelname>": "<labelvalue>", ... } }, ... ] ``` Examples: ```json [ { "targets": ["10.0.10.2:9100", "10.0.10.3:9100", "10.0.10.4:9100", "10.0.10.5:9100"], "labels": { "meta_datacenter": "london", "metaprometheusjob": "node" } }, { "targets": ["10.0.40.2:9100", "10.0.40.3:9100"], "labels": { "meta_datacenter": "london", "metaprometheusjob": "alertmanager" } }, { "targets": ["10.0.40.2:9093", "10.0.40.3:9093"], "labels": { "meta_datacenter": "newyork", "metaprometheusjob": "alertmanager" } } ] ```
Project: HertzBeat (Observability and Analysis / Observability)
File: extend-http-default.md

id: extend-http-default title: HTTP Protocol System Default Parsing Method sidebar_label: Default Parsing Method After calling the HTTP api to obtain the response data, use the default parsing method of hertzbeat to parse the response data. The interface response data structure must be consistent with the data structure rules specified by hertzbeat Note The response data is JSON format. Single layer format key-value ```json { "metricName1": "metricValue", "metricName2": "metricValue", "metricName3": "metricValue", "metricName4": "metricValue" } ``` Multilayer formatSet key value in the array ```json [ { "metricName1": "metricValue", "metricName2": "metricValue", "metricName3": "metricValue", "metricName4": "metricValue" }, { "metricName1": "metricValue", "metricName2": "metricValue", "metricName3": "metricValue", "metricName4": "metricValue" } ] ``` eg Query the CPU information of the custom system. The exposed interface is `/metrics/cpu`. We need `hostname,core,useage` Metric. If there is only one virtual machine, its single-layer format is : ```json { "hostname": "linux-1", "core": 1, "usage": 78.0, "allTime": 200, "runningTime": 100 } ``` If there are multiple virtual machines, the multilayer format is: : ```json [ { "hostname": "linux-1", "core": 1, "usage": 78.0, "allTime": 200, "runningTime": 100 }, { "hostname": "linux-2", "core": 3, "usage": 78.0, "allTime": 566, "runningTime": 34 }, { "hostname": "linux-3", "core": 4, "usage": 38.0, "allTime": 500, "runningTime": 20 } ] ``` The corresponding monitoring template yml can be configured as follows ```yaml category: custom app: example name: zh-CN: en-US: EXAMPLE APP 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: 80 placeholder: 'Please enter the port' metrics: name: cpu priority: 0 fields: field: hostname type: 1 label: true field: usage type: 0 unit: '%' field: core type: 0 protocol: http http: host: ^^host^^ port: ^^port^^ url: /metrics/cpu method: GET ssl: false parseType: default ```
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: loggly.md

title: Loggly output weight: 200 generated_file: true More info at https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/43#TOPIC-1829072 Address of the destination host Default: - Event tag Default: - Your Customer Token that you received from Loggly Default: - syslog output configuration Default: -
Project: Netdata (Observability and Analysis / Observability)
File: web_log_1m_bad_requests.md

HTTP response status codes indicate whether a specific HTTP request has been successfully completed or not. The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. The Netdata Agent calculates the ratio of client error HTTP requests over the last minute. This metric does not include the 401 errors. To identify the HTTP response code your web server sends back: Open the Netdata dashboard. Inspect the `detailedresponsecodes` chart for your web server. This chart keeps track of exactly what error codes your web server sends out. You should also check server logs for more details about how the server is handling the requests. For example, web servers such as Apache or Nginx produce two files called access.log and error.log (by default under `/var/log/{nginx, apache2}/{access.log, error.log}`) Troubleshoot 404 codes on the server side The 404 requests indicate outdated links on your website or in other websites that redirect to your website. To check for dead links on your on website, use a `broken link checker` software periodically.
Project: Checkmk (Observability and Analysis / Observability)
File: 16526.md

key | value | date | 2024-03-07T09:18:40+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes This werk addresses an issue with the REST-API password endpoint response. The response schema listed the title and the ident as fields that should be returned but we were not returning them as part of the password object. These have now been removed from the schema. Also, the members field was returning invalid information and hence has been removed.
Project: HertzBeat (Observability and Analysis / Observability)
File: README.md

[!NOTE] HertzBeat Web-App is a fork to . Check and for more details. Need `Node Yarn` Environment, Make sure `Node.js >= 18` Install yarn if not existed `npm install -g yarn` Execute `yarn install` or `yarn install --registry=https://registry.npmmirror.com` in `web-app` Install angular-cli : `yarn global add @angular/cli@15` or `yarn global add @angular/cli@15 --registry=https://registry.npmmirror.com` Start After Backend Server Available : `ng serve --open` Execute command in web-app ```ng build --configuration production``` Execute command in root ```mvn clean install``` The HertzBeat install package will at `manager/target/hertzbeat-{version}.tar.gz` Execute command in collector ```mvn clean package -Pcluster```
Project: HertzBeat (Observability and Analysis / Observability)
File: 2023-05-09-hertzbeat-v1.3.1.md

title: Open source real-time monitoring tool HertzBeat v1.3.1 released author: tom author_title: tom author_url: https://github.com/tomsun28 authorimageurl: https://avatars.githubusercontent.com/u/24788200?s=400&v=4 tags: [opensource, practice] keywords: [open source monitoring system, alerting system, Linux monitoring] Website: hertzbeat.com | tancloud.cn is an open source, real-time monitoring system with custom-monitoring and agentLess. Monitoring+Alarm+Notify all in one. Support monitoring web service, database, os, middleware, cloud-native, network and more. Easy to use, full web-based operation, monitoring and alerting at the click of a mouse, zero learning cost. More flexible threshold rule, timely notification delivery by `Discord` `Slack` `Telegram` `Email` `DingDing` `WeChat` `FeiShu` `Webhook` `SMS`. We make protocols such as `Http, Jmx, Ssh, Snmp, Jdbc, Prometheus` configurable, and you only need to configure `YML` online to collect any metrics you want. Do you believe that you can immediately adapt a new monitoring type such as K8s or Docker just by configuring online? `HertzBeat`'s powerful custom-define, multi-type support, easy expansion, low coupling, hope to help developers and micro teams to quickly build their own monitoring system. We also provide , users no longer need to deploy a cumbersome monitoring system in order to monitor resources. . Github: https://github.com/apache/hertzbeat Gitee: https://gitee.com/hertzbeat/hertzbeat Hi guys! Major release. HertzBeat v1.3.1 is coming. So excited that more than 30 friends have contributed this version.. We support greptimeDB, tedngine3.0 and opengauss influxdb to store to metrics data. New feature monitoring export and import by excel json yaml , alert silence, new monitoring template and more. Support monitoring EulerOS metrics and SpringBoot3 metrics. Fixed several bugs, imporved document and improved the overall stable usability. Let's Try Now! Only one docker command is needed to install and experience hertzbeat `docker run -d -p 1157:1157 --name hertzbeat apache/hertzbeat` If use tdengine before, please upgrade tdengine to 3.0+ Please Run SQL Script When Upgrade. ``` ALTER table hzbalertdefine modify field varchar(255) default null; COMMIT; ``` Site Monitor, Port Availability, Http Api, Ping Connectivity, Jvm, SiteMap Full Site, Ssl Certificate, SpringBoot, FTP Server Mysql, PostgreSQL, MariaDB, Redis, ElasticSearch, SqlServer, Oracle, MongoDB, Damon, OpenGauss, ClickHouse, IoTDB, Redis Cluster Linux, Ubuntu, CentOS, Windows Tomcat, Nacos, Zookeeper, RabbitMQ, Flink, Kafka, ShenYu, DynamicTp, Jetty, ActiveMQ Kubernetes, Docker Huawei Switch, HPE Switch, TP-LINK Switch, Cisco Switch and more for your custom monitoring. Notifications support `Discord` `Slack` `Telegram` `Mail` `Pinning` `WeChat` `FlyBook` `SMS` `Webhook`. Github: https://github.com/apache/hertzbeat Gitee: https://gitee.com/hertzbeat/hertzbeat
Project: Vector (Observability and Analysis / Observability)
File: kubernetes_logs.md

title: Kubernetes logs description: Collect logs from Nodes component_kind: source layout: component tags: ["kubernetes", "k8s", "node", "component", "source", "logs"] {{/* 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: 16466.md

key | value | date | 2024-02-09T06:58:10+00:00 version | 2.4.0b1 class | feature edition | cre component | wato level | 1 compatible | yes Prior to this werk, it was not possible to update only the discovered labels of a service. Updating those were tied to updating the identified parameters of the service. This werk introduces the option to update the discovered service labels only automatically as well as manually. The following changes were made to introduce this option as well for better visibility: Service discovery page: changed services due to a change in their labels are now listed under 'Changed services'. Service labels can be manually updated with dedicated actions targeting all changed services or a specific service Check_MK Discovery service: the service now accounts for changed services due to label changes. The state of the discovery service for such cases can also be configured Bulk discovery & Periodic service discovery: now have the option to update labels of changed services
Project: Vector (Observability and Analysis / Observability)
File: DEPRECATIONS.md

See for the process for updating this file. The format for each entry should be: `<version> <identifier> <description>`. `<version>` should be the version of Vector in which to take the action (deprecate, migrate, or remove) `<identifier>` should be a unique identifier that can also be used in the code to easily find the places to modify `<description>` should be a longer form description of the change to be made For example: v0.34.0 legacyopensslprovider OpenSSL legacy provider flag should be removed v0.39.0 enterprise_feature The `enterprise` feature has been deprecated and will be removed.
Project: Botkube (Observability and Analysis / Observability)
File: botkube_config.md

title: botkube config This command consists of multiple subcommands for working with Botkube configuration ``` -h, --help help for config ``` ``` -v, --verbose int/string[=simple] Prints more verbose output. Allowed values: 0 - disable, 1 - simple, 2 - trace (default 0 - disable) ``` - Botkube CLI - Displays Botkube configuration
Project: Netdata (Observability and Analysis / Observability)
File: interface_speed.md

This alert indicates the current speed of the network interface `${label:device}`. If you receive this alert, it means that there is a significant change or reduction in the speed of your network interface. Interface speed refers to the maximum throughput an interface (network card or adapter) can support in terms of transmitting and receiving data. It is measured in Megabits per second (Mbit/s) and determines the performance of a network connection. Check the network interface speed. To see the interface speed and other information about the network interface, run the following command in the terminal: ``` ethtool ${label:device} ``` Replace `${label:device}` with your network interface name, e.g., `eth0` or `enp2s0`. Confirm if there is a network congestion issue. High network traffic or congestion might cause reduced interface speed. Use the `iftop` utility to monitor the traffic on the network interface. If you don't have `iftop` installed, then . Run the following command in the terminal: ``` sudo iftop -i ${label:device} ``` Replace `${label:device}` with your network interface name. Verify cable connections and quality. Physical cable issues might cause reduced speed in the network interface. Check the connections and quality of the cables connecting your system to the network devices such as routers, switches, or hubs. Update network drivers. Outdated network drivers can also lead to reduced speed in the network interface. Update the network drivers to the latest version to avoid any compatibility issues or performance degradations. Check for EMI (Electromagnetic Interference). Network cables and devices located near power cables or electronic devices producing electromagnetic fields might experience reduced network interface speed. Make sure that your network cables and devices are not in proximity to potential sources of EMI.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-4-5.md

hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 8.4.5 <!-- Auto generated by update changelog github action --> Instrumentation: Make backend plugin metrics endpoints available with optional authentication. , Table panel: Show datalinks for cell display modes JSON View and Gauge derivates. , Azure Monitor: Small bug fixes for Resource Picker. , Logger: Use specified format for file logger. , Logs: Handle missing fields in dataframes better. , ManageDashboards: Fix error when deleting all dashboards from folder view. ,
Project: Checkmk (Observability and Analysis / Observability)
File: 16621.md

key | value | date | 2024-03-11T13:47:41+00:00 version | 2.4.0b1 class | fix edition | cre component | wato level | 1 compatible | no As the name indicates, the previous `Tuple` FormSpec should no longer be used and with this will no longer be available in the API. Use `SimpleLevels` or `Levels` instead if you want to configure levels or a `Dictionary` otherwise.