cwielenb/CNCF-Dataset huggingface dataset:
Project: SkyWalking (Observability and Analysis / Observability)
File: Why-have-traces-no-others.md

There is no abnormal log in Agent log and Collector log. The traces can be seen, but no other information is available in UI. The operating system where the monitored system is located is not set as the current time zone, causing statistics collection time points to deviate. Make sure the time is synchronized between collector servers and monitored application servers.
Project: Ddosify (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: enhancement assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: Grafana Loki (Observability and Analysis / Observability)
File: sampling.md

title: sampling menuTitle: description: The 'sampling' Promtail pipeline stage. aliases: ../../../clients/promtail/stages/sampling/ weight: The `sampling` stage is a stage that sampling logs. The `sampling` stage is used to sampling the logs. Configuring the value `rate: 0.1` means that 10% of the logs will be pushed to the Loki server. ```yaml sampling: [rate: <int>] ``` The following are examples showing the use of the `sampling` stage. Given the pipeline: ```yaml sampling: rate: 0.1 ``` Given the pipeline: ```yaml pipeline_stages: json: expressions: app: match: pipeline_name: "app2" selector: '{app="poki"}' stages: sampling: rate: 0.1 ``` Complex `sampling` stage configurations.
Project: Netdata (Observability and Analysis / Observability)
File: httpcheck_web_service_timeouts.md

This alert is triggered when the percentage of timed-out HTTP requests to a specific URL goes above a certain threshold in the last 5 minutes. The alert levels are determined by the following percentage thresholds: Warning: 10% to 40% Critical: 40% or higher The alert is designed to notify you about potential issues with the accessed HTTP endpoint. An HTTP request timeout occurs when a client (such as a web browser) sends a request to a webserver but does not receive a response within the specified time period. This can lead to a poor user experience, as the user may be unable to access the requested content or services. Verify the issue Check the HTTP endpoint to see if it is responsive and reachable. You can use tools like `curl` or online services like <https://www.isitdownrightnow.com/> to check the availability of the website or service. Analyze server logs Examine the server logs for any error messages or unusual patterns of behavior that may indicate a root cause for the timeout issue. For web servers such as Apache or Nginx, look for log files located in the `/var/log` directory. Check resource usage High resource usage, such as CPU, memory, or disk I/O, can cause HTTP request timeouts. Use tools like `top`, `vmstat`, or `iotop` to identify resource-intensive processes. Address any performance bottlenecks by resizing the server, optimizing performance, or distributing the load across multiple servers. Review server configurations Make sure your web server configurations are optimized for performance. For instance: Ensure that the `KeepAlive` feature is enabled and properly configured. Make sure that your server's timeout settings are appropriate for the type of traffic and workload it experiences. Confirm that your server is correctly configured for the number of concurrent connections it handles. Verify network configurations Examine the network configurations for potential issues that can lead to HTTP request timeouts. Check for misconfigured firewalls or faulty load balancers that may be interfering with traffic to the HTTP endpoint.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: v5.3.md

title: "Grafana Mimir Helm chart version 5.3 release notes" menuTitle: "V5.3 release notes" description: "Release notes for Grafana Mimir Helm chart version 5.3" weight: 300 Grafana Labs is excited to announce version 5.3 of the Grafana Mimir Helm chart, which is compatible with Grafana Mimir v2.12 or Grafana Enterprise Metrics (GEM) v2.12. The `mimir-distributed` Helm chart is the best way to install Mimir on Kubernetes. The highlights that follow include the top features, enhancements, and bug fixes in this release. For a comprehensive list of changes, see the . A number of timeout settings have been improved upon: Relaxed the hash ring heartbeat period and timeout for the distributor, ingester, store-gateway and compactor. This reduces load in intra component communication with the tradeoff that abrupt component failures take longer to detect. The new values are taken from Grafana Cloud Metrics operations. Increased the timeout for writing recording rule results to `10s` to accommodate large result sets. Increased the distributor termination grace period from `60s` to `100s` to give more time for a clean termination. Increased the read timeout for chunks and index caches using memcached from `450ms` to `750ms`. Tuned the GRPC maximum connection age and shutdown delay for the distributor and query-frontend components to avoid invoking components that are shutting down. Notable enhancements are as follows: Added experimental feature for deploying ScaledObjects as part of the helm chart for the components: distributor, querier, query-frontend and ruler. For more details please see the values sections `kedaAutoscaling`, `distributor.kedaAutoscaling`, `ruler.kedaAutoscaling`, `query_frontend.kedaAutoscaling`, and `querier.kedaAutoscaling`, and the . Gateway: Added option for configuring whether or not NGINX binds IPv6: `gateway.nginx.config.enableIPv6`.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: record_transformer.md

title: Record Transformer weight: 200 generated_file: true Mutates/transforms incoming event streams. Use original value type. Default: true When set to true, the full Ruby syntax is enabled in the `${...}` expression. Default: false A comma-delimited list of keys to keep. Add records docs at: https://docs.fluentd.org/filter/record_transformer Records are represented as maps: `key: value` A comma-delimited list of keys to delete Create new Hash to transform incoming data Default: false Specify field name of the record to overwrite the time of events. Its value must be unix time. {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: demo-flow spec: filters: record_transformer: records: foo: "bar" selectors: {} localOutputRefs: demo-output {{</ highlight >}} Fluentd config result: {{< highlight xml >}} <filter > @type record_transformer @id testrecordtransformer <record> foo bar </record> </filter> {{</ highlight >}}
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: resource-optimize-model.md

title: "Application Resource Optimize Model" description: "Application Resource Optimize Model" weight: 11 Resource optimization is a common optimization strategy in FinOps. Based on the characteristics of Kubernetes applications, we have summarized the resource optimization model for cloud-native applications: The five lines in the figure from top to bottom are: Node capacity: the total resources of all nodes in the cluster, corresponding to the Capacity of the cluster Allocated: the total resources applied by the application, corresponding to Pod Request Weekly peak usage: the peak resource usage of the application in the past period. The weekly peak can predict the resource usage in the future period. Configuring resource specifications based on weekly peak can ensure higher security and stronger versatility. Daily peak usage: the peak resource usage of the application in one day Average usage: the average resource usage of the application, corresponding to Usage There are two types of idle resources: Resource Slack: the difference between Capacity and Request Usage Slack: the difference between Request and Usage Total Slack = Resource Slack + Usage Slack The goal of resource optimization is to reduce Resource Slack and Usage Slack. The model provides four steps for reducing waste, from top to bottom: Improve packing rate: improving packing rate can make Capacity and Request closer. There are many methods, such as , Tencent Cloud native node's node enlargement function, etc. Adjust application requests to reduce resource locking: adjust application specifications based on the weekly peak resource usage to reduce Request to the weekly peak line. and can help applications achieve this goal. Application requests adjustment + scaling to cope with sudden traffic bursts: based on the request optimization, use HPA to cope with sudden traffic bursts, and reduce Request to the daily average peak line. At this time, the target utilization rate of HPA is low, only for coping with sudden traffic, and autoscaling does not occur most of the time. can scan out applications suitable for elasticity and provide HPA configuration. Application requests adjustment + scaling to cope with daily traffic changes: based on the request optimization, use HPA to cope with daily traffic and reduce Request to the average. At this time, the target utilization rate of HPA is equal to the average utilization rate of the application. provide prediction-based horizontal elasticity, helping more applications achieve intelligent elasticity.
Project: SkyWalking (Observability and Analysis / Observability)
File: Memory-leak-enhance-Worker-thread.md

When using a thread pool, `TraceSegment` data in a thread cannot be reported and there are memory data that cannot be recycled (memory leaks). ``` java ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setThreadFactory(r -> new Thread(RunnableWrapper.of(r))); ``` Worker threads are enhanced when using the thread pool. Based on the design of the SkyWalking Java Agent, when tracing a cross thread, you must enhance the task thread. When using `Thread Schedule Framework`: See SkyWalking Thread Schedule Framework at , such as Spring FrameWork @Async, which can implement tracing without any modification. When using `Custom Thread Pool`: Enhance the task thread with the following code. ```java ExecutorService executorService = Executors.newFixedThreadPool(1); executorService.execute(RunnableWrapper.of(new Runnable() { @Override public void run() { //your code } })); ``` See for more use cases.
Project: Cortex (Observability and Analysis / Observability)
File: prometheus-frontend.md

title: "Prometheus Frontend" linkTitle: "Prometheus Frontend" weight: 3 slug: prometheus-frontend You can use the Cortex query frontend with any Prometheus-API compatible service, including Prometheus and Thanos. Use this config file to get the benefits of query parallelisation and caching. ```yaml auth_enabled: false target: query-frontend http_prefix: server: httplistenport: 9091 query_range: splitqueriesby_interval: 24h alignquerieswith_step: true cache_results: true forwardheaderslist: Authorization results_cache: cache: enable_fifocache: true fifocache: size: 1024 validity: 24h frontend: logquerieslonger_than: 1s compress_responses: true downstream_url: http://prometheus.mydomain.com ```
Project: K8sGPT (Observability and Analysis / Observability)
File: SECURITY.md

We currently support the latest release for security patching and will deploy forward releases. For example if there is a vulnerability in release `0.1.0` we will fix that release in version `0.1.1-fix` or `0.1.1` If you are aware of a vulnerability please feel free to disclose it responsibly to contact@k8sgpt.ai or to one of our maintainers in our Slack community.
Project: HertzBeat (Observability and Analysis / Observability)
File: template.md

id: template title: Monitoring Template Here sidebar_label: Monitoring Template Hertzbeat is an open source, real-time monitoring tool with custom-monitor and agentLess. 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? Here is the architecture. We define all monitoring collection types (mysql, website, jvm, k8s) as yml templates, and users can import these templates into the hertzbeat system to support corresponding types of monitoring, which is very convenient! Welcome everyone to contribute your customized general monitoring type YML template during use. The available templates are as follows: &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> &emsp;&#x1F449;&emsp; <br /> Have Fun!
Project: SkyWalking (Observability and Analysis / Observability)
File: kafka-fetcher.md

The Kafka Fetcher pulls messages from the Kafka Broker to learn about what agents have delivered. Check the agent documentation for details on how to enable the Kafka reporter. Typically, tracing segments, service/instance properties, JVM metrics, and meter system data are supported (depending on the agent implementation). Kafka Fetcher can work with gRPC/HTTP Receivers simultaneously for adopting different transport protocols. Kafka Fetcher is disabled by default. To enable it, configure it as follows. Namespace aims to isolate multi OAP clusters when using the same Kafka cluster. If you set a namespace for Kafka fetcher, the OAP will add a prefix to the topic name. You should also set the namespace in the property named `plugin.kafka.namespace` in `agent.config`. ```yaml kafka-fetcher: selector: ${SWKAFKAFETCHER:default} default: bootstrapServers: ${SWKAFKAFETCHER_SERVERS:localhost:9092} namespace: ${SW_NAMESPACE:""} ``` `skywalking-segments`, `skywalking-metrics`, `skywalking-profilings`, `skywalking-managements`, `skywalking-meters`, `skywalking-logs` and `skywalking-logs-json` topics are required by `kafka-fetcher`. If they do not exist, Kafka Fetcher will create them by default. Also, you can create them by yourself before the OAP server starts. When using the OAP server automatic creation mechanism, you could modify the number of partitions and replications of the topics using the following configurations: ```yaml kafka-fetcher: selector: ${SWKAFKAFETCHER:default} default: bootstrapServers: ${SWKAFKAFETCHER_SERVERS:localhost:9092} namespace: ${SW_NAMESPACE:""} partitions: ${SWKAFKAFETCHER_PARTITIONS:3} replicationFactor: ${SWKAFKAFETCHERPARTITIONSFACTOR:2} consumers: ${SWKAFKAFETCHER_CONSUMERS:1} ``` When using Kafka MirrorMaker 2.0 to replicate topics between Kafka clusters, you can set the source Kafka Cluster alias (mm2SourceAlias) and separator (mm2SourceSeparator) according to your Kafka MirrorMaker . ```yaml kafka-fetcher: selector: ${SWKAFKAFETCHER:default} default: bootstrapServers: ${SWKAFKAFETCHER_SERVERS:localhost:9092} namespace: ${SW_NAMESPACE:""} partitions: ${SWKAFKAFETCHER_PARTITIONS:3} replicationFactor: ${SWKAFKAFETCHERPARTITIONSFACTOR:2} consumers: ${SWKAFKAFETCHER_CONSUMERS:1} mm2SourceAlias: ${SWKAFKAMM2SOURCEALIAS:""} mm2SourceSeparator: ${SWKAFKAMM2SOURCESEPARATOR:""} kafkaConsumerConfig: enable.auto.commit: true ... ```
Project: Icinga (Observability and Analysis / Observability)
File: release.md

name: '[INTERNAL] Release' about: Release a version title: 'Release Version v$version' labels: '' assignees: '' [ ] Update `ICINGA2_VERSION` [ ] Update bundled Windows dependencies [ ] Harden global TLS defaults (consult https://ssl-config.mozilla.org) [ ] Update `CHANGELOG.md` [ ] Create and push a signed tag for the version [ ] Build and release DEB and RPM packages [ ] Build and release Windows packages [ ] Merge dependency updates in https://github.com/Icinga/docker-icinga2/pulls [ ] Create release on GitHub [ ] Update public docs [ ] Announce release Add the latest Boost and OpenSSL versions to https://packages.icinga.com/windows/dependencies/, e.g.: https://master.dl.sourceforge.net/project/boost/boost-binaries/1.82.0/boost182_0-msvc-14.2-64.exe https://master.dl.sourceforge.net/project/boost/boost-binaries/1.82.0/boost182_0-msvc-14.2-32.exe https://slproweb.com/download/Win64OpenSSL-309.exe https://slproweb.com/download/Win32OpenSSL-309.exe (also affects CI/CD) Even if there aren't any new releases of dependencies with versions hardcoded in the repos and files listed above (Boost, OpenSSL). There may be new build versions of other dependencies (VS, MSVC). Our GitHub actions (tests) use the latest ones automatically, but the GitLab runner (release packages) doesn't.
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.ErrorBoundaryEvent.md

title: "Interface: ErrorBoundaryEvent" linkTitle: "ErrorBoundaryEvent" slug: "plugin_registry.ErrorBoundaryEvent" .ErrorBoundaryEvent Event fired when an error boundary is triggered. data: `Error` The error that was thrown. _ type: `ERROR_BOUNDARY`
Project: Vector (Observability and Analysis / Observability)
File: internal_metrics.md

title: Internal metrics description: Access to the metrics produced by Vector itself and process them in your Vector pipeline component_kind: source layout: component tags: ["vector", "instance", "local", "internal", "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: 16633.md

key | value | date | 2024-04-17T08:10:14+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes The "Logfile pattern analyzer" page crashed when the first "Logfile pattern" rule in place did not hold a regex pattern and a later rule did hold a regex pattern. The rendering of the table of rules would crash with ``` Internal error: list index out of range ``` This is fixed and all rules are rendered as expected.
Project: Grafana Loki (Observability and Analysis / Observability)
File: prepare-upgrade-guide.md

title: Prepare Upgrade guide description: Prepare Upgrade guide The upgrade guide records changes that require user attention or interaction to upgrade to specific Loki version from previous versions. The upgrade guide in Grafana Loki works as follows. We have a `setup/upgrade/_index.md` file that records upgrade information for all Loki releases. Make sure the upgrade guide is up to date on the `release-VERSION_PREFIX` branch under the `Main/Unreleased` section. On the `release-VERSION_PREFIX` branch promote `Main/Unreleased` to `VERSION`. Example . On the `main` branch remove entries from `Main/Unreleased` that are already part of `VERSION (YYY-MM-DD)`.
Project: Elastic (Observability and Analysis / Observability)
File: to_unsigned_long.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 an unsigned long value. If the input parameter is of a date type, its value will be interpreted as milliseconds since the Unix epoch, converted to unsigned long. Boolean true will be converted to unsigned long 1, false to 0. ``` ROW str1 = "2147483648", str2 = "2147483648.2", str3 = "foo" | EVAL long1 = TOUNSIGNEDLONG(str1), long2 = TOULONG(str2), long3 = TOUL(str3) ```
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-team_info_by_name.md

category: Team apiurl: '/api/v1/team/name/#{team_name}' title: "Get Team Info by name" type: 'GET' sample_doc: 'team.html' layout: default Required ex. /api/v1/team/name/plus-dev ```Status: 200``` ``` { "creator": 6, "creator_name": "", "id": 10, "name": "plus-dev", "resume": "test intro", "users": [ { "cnname": "laiwei", "email": "laiwei@xxx.com", "id": 1, "im": "yyyyx", "name": "laiwei1", "phone": "15011518472", "qq": "3805112124444455", "role": 2 } ] }```
Project: Vector (Observability and Analysis / Observability)
File: 2022-06-07-vrl-metadata-and-secrets.md

date: "2022-06-07" title: "Updates to event metadata and secrets" description: "Updates to event metadata and secrets" authors: ["fuchsnj"] pr_numbers: [12767] release: "0.23.0" hideonrelease_notes: false badges: type: enhancement VRL already contained three methods for working with metadata. `setmetadatafield` `getmetadatafield` `removemetadatafield` However, these were restricted to only storing a datadog api key, or splunk hec token, which were used by some sinks. These functions have been expanded to support using arbitrary keys (the full path syntax is supported) and can also store arbitrary data, similar to normal event data today. To replace the existing functionality these provided, new "secret" functions have been added. `set_secret` `get_secret` `remove_secret` These functions allow storage of arbitrary secrets, and should now be used instead of the metadata functions. They securely store a map of string keys to string values. All of these changes were backwards compatible. Secrets that were previously stored using the metadata functions will still be used by sinks, and will also be accessible through the new secret functions. It is encouraged to upgrade to the secret functions immediately. Here are some examples using the new features ```coffeescript setmetadatafield("datadogapikey", "my secret key") setsecret("datadogapi_key", "my secret key") getmetadatafield("datadogapikey") getsecret("datadogapi_key") setmetadatafield(.foo.bar, "my metadata") setmetadatafield(.foo.baz, {"msg": "Any VRL type is supported"}) getmetadatafield(.) ``` These changes are forming the basis for many future plans we have. These include: Adding special syntax to access metadata. Right now you have to use the metadata functions, but we'd like to improve that even more Expanding VRL type definition support to metadata. Right now values may be more difficult to work with since they are lacking type definitions Add more security around secret storage, such as potentially encryption at rest.