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

This issue was found in our . A user installed the SkyWalking Java agent on WebSphere 7.0.0.11 and ibm jdk 1.820160719 and 1.7.020150407, and experienced the following error logs: ``` WARN 2019-05-09 17:01:35:905 SkywalkingAgent-1-GRPCChannelManager-0 ProtectiveShieldMatcher : Byte-buddy occurs exception when match type. java.lang.IllegalStateException: Cannot resolve type description for java.security.PrivilegedAction at org.apache.skywalking.apm.dependencies.net.bytebuddy.pool.TypePool$Resolution$Illegal.resolve(TypePool.java:144) at org.apache.skywalking.apm.dependencies.net.bytebuddy.pool.TypePool$Default$WithLazyResolution$LazyTypeDescription.delegate(TypePool.java:1392) at org.apache.skywalking.apm.dependencies.net.bytebuddy.description.type.TypeDescription$AbstractBase$OfSimpleType$WithDelegation.getInterfaces(TypeDescription.java:8016) at org.apache.skywalking.apm.dependencies.net.bytebuddy.description.type.TypeDescription$Generic$OfNonGenericType.getInterfaces(TypeDescription.java:3621) at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.HasSuperTypeMatcher.hasInterface(HasSuperTypeMatcher.java:53) at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.HasSuperTypeMatcher.hasInterface(HasSuperTypeMatcher.java:54) at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.HasSuperTypeMatcher.matches(HasSuperTypeMatcher.java:38) at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.HasSuperTypeMatcher.matches(HasSuperTypeMatcher.java:15) at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.ElementMatcher$Junction$Conjunction.matches(ElementMatcher.java:107) at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.ElementMatcher$Junction$Disjunction.matches(ElementMatcher.java:147) at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.ElementMatcher$Junction$Disjunction.matches(ElementMatcher.java:147) at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.ElementMatcher$Junction$Disjunction.matches(ElementMatcher.java:147) at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.ElementMatcher$Junction$Disjunction.matches(ElementMatcher.java:147) at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.ElementMatcher$Junction$Disjunction.matches(ElementMatcher.java:147) ... ``` The exception occurred because access grant was required in WebSphere. Simply follow these steps: Set the agent's owner to the owner of WebSphere. Add "grant codeBase "file:${agent_dir}/-" { permission java.security.AllPermission; };" in the file of "server.policy".
Project: Checkmk (Observability and Analysis / Observability)
File: 16465.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-01-29T10:23:24+00:00 level | 1 class | fix component | rest-api edition | cre Prior to this werk, the service discovery endpoints were restricted to the local service discovery background job. This resulted in the following endpoints being restricted to local setups only: Show the last service discovery background job on a host Wait for service discovery completion This werk fixes this and now also supports distributed monitoring setups. To benefit from this change both the central site as well the remote sites need to be updated to the werk's version. This change does not affect local only setups.
Project: Promscale (Observability and Analysis / Observability)
File: PromscaleMaintenanceJobFailures.md

Promscale maintenance jobs failed to execute successfully Delay in compression and retention policy, leading to high disk usage Open psql Run the following debugging query: ```postgresql select * from timescaledbinformation.jobstats stats inner join timescaledb_information.jobs jobs on jobs.jobid = stats.jobid where jobs.procname = 'executemaintenance_job'; ``` This will give you information about the maintenance jobs. The `lastrunstatus` column will indicate any failed jobs. For mitigation, see Check Postgres logs for any failure Run the following debugging query ```postgresql SELECT * FROM timescaledbinformation.jobstats js INNER JOIN timescaledbinformation.jobs j USING (jobid) WHERE procname ='executemaintenance_job'; ``` If the output has: no rows => No jobs are installed `SELECT promapi.configmaintenancejobs(numberjobs => 2, newscheduleinterval => '30 minutes'::interval)` lastrunstatus not = 'Success' => Job had an error Run `CALL promapi.executemaintenance(true);` and see if there are any obvious errors job_status != 'Scheduled' => Job disabled next_start not within 30 min Try increasing maintenance jobs and see if it helps: `SELECT promapi.configmaintenancejobs(numberjobs => X, newscheduleinterval => '30 minutes'::interval)` If some problem persists with scheduling, then please open an issue at https://github.com/timescale/promscale/issues lastrunduration is high (>30 min) => Not enough parallelism Increase the number of maintenance jobs N using `SELECT promapi.configmaintenancejobs(numberjobs => N, newscheduleinterval => '30 minutes'::interval)`
Project: Grafana Tempo (Observability and Analysis / Observability)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: intuit.md

is a product company known for Quickbooks and TurboTax. We contribute to open source, and a few of our notable projects are Argo, Karate, and Keiko. Our Group, The Intuit Modern SaaS Platform, is a developer platform for automating development, building, deployment, scaling, and managing containerized and serverless applications. It provides a cohesive and straightforward Developer Experience and abstracts infrastructure complexities by implementing Intuit specific security, compliance, and network policies on top of open-source Kubernetes(k8s) and AWS services. This platform aims to provide automation at scale, resulting in higher developer productivity and significantly increased velocity. When we started building our next-gen platform on kubernetes , we realized that its reliability is most important. We started using the litmus base solution. We have our homegrown solution build on kubernetes with a container-native approach, using . We need a solution that can reuse the work and help in building kubernetes native way. We use litmuschaos on the cluster as an operator and create custom resources for experiments. Those experiments will be exposed and executed via the test using Argo workflow. In the future, we are planning to go gitOps for chaos. We have a cluster and service owner use case to handle separate role access to execute this chaos. We are using Chaos for Application, cloud, and kubernetes platform. We are attaching chaos with Performance testing to get the full impact of chaos on the given service. We are getting benefits from its plug-in architecture. With open-source and community-backed up, we could move fast if we face any challenges. I have shared our and how we are using Choas Workflow and Chaos gitOps using .
Project: Loggie (Observability and Analysis / Observability)
File: SECURITY.md

Join the [kubernetes-security-announce] group for security and vulnerability announcements. You can also subscribe to an RSS feed of the above using . Instructions for reporting a vulnerability can be found on the [Kubernetes Security and Disclosure Information] page. Information about supported Kubernetes versions can be found on the [Kubernetes version and version skew support policy] page on the Kubernetes website.
Project: Netdata (Observability and Analysis / Observability)
File: vsphere_cpu_usage.md

The `vspherecpuusage` alert monitors the average CPU utilization of virtual machines in the vSphere platform. The alert is triggered in a warning state when the CPU utilization is between 75-85% and in a critical state when it is between 85-95%. High CPU usage indicates that the virtual machine's CPU resources are being heavily utilized. This can lead to performance issues, slow response times, and decreased stability. Confirm the high CPU usage by logging into the vSphere management console and checking the CPU performance metrics for the affected virtual machine(s). Identify the cause of high CPU usage: Check the virtual machine's running processes to identify any resource-intensive applications or services. You can use the `top` command on Linux-based virtual machines or Task Manager on Windows-based virtual machines. Inspect application logs and system logs for any signs of issues, errors, or crashes that could be contributing to high CPU usage. Verify if the virtual machine has adequate CPU resources allocated. If the virtual machine is consistently using a high percentage of its allocated CPU resources, consider increasing the allocated CPU resources. Remediate the issue: If an application or service is responsible for the high CPU usage, try restarting it or addressing the specific issue causing the problem. If the virtual machine is consistently using a high percentage of its allocated CPU resources, consider increasing the allocated CPU resources or optimizing the virtual machine's performance through application and OS tuning. Monitor the CPU usage after making changes to ensure that the issue has been resolved.
Project: SkyWalking (Observability and Analysis / Observability)
File: virtual-cache.md

Virtual cache represent the cache nodes detected by . The performance metrics of the cache are also from the Cache client-side perspective. For example, Redis plugins in the Java agent could detect the latency of command As a result, SkyWalking would show traffic, latency, success rate, and sampled slow operations(write/read) powered by backend analysis capabilities in this dashboard. The cache operation span should have It is an Exit or Local span Span's layer == CACHE Tag key = `cache.type`, value = The type of cache system , e.g. redis Tag key = `cache.op`, value = `read` or `write` , indicates the value of tag `cache.cmd` is used for `write` or `read` operation Tag key = `cache.cmd`, value = the cache command , e.g. get,set,del Tag key = `cache.key`, value = the cache key If the cache system is in-memory (e.g. Guava-cache), agents' plugin would create a local span usually, and the span's peer would be null ,otherwise the peer is the network address(IP or domain) of Cache server. Ref to know more slow Cache commands settings.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: vmware_loginsight.md

title: VMware LogInsight weight: 200 generated_file: true For details, see . ```yaml spec: vmwareLogInsight: scheme: https ssl_verify: true host: MYLOGINSIGHTHOST port: 9543 agent_id: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX logtextkeys: log msg message httpconndebug: false ``` Send your logs to VNMware LogInsight agent_id generated by your LI Default: 0 Type of authentication to use (nil,basic) Default: nil Rename fields names Default: {"source" => "log_source"} Flatten hashes to create one key/val pair w/o losing log data Default: true Separator to use for joining flattened keys Default: _ If set, enables debug logs for http connection Default: false HTTP method (post) Default: post VMware Aria Operations For Logs Host ex. localhost Keys from log event whose values should be added as log message/text to VMware Aria Operations For Logs. These key/value pairs won't be expanded/flattened and won't be added as metadata/fields. Default: ["log", "message", "msg"] Number of bytes per post request Default: 4000000 VMware Aria Operations For Logs ingestion api path ex. 'api/v1/events/ingest' Default: api/v1/events/ingest VMware Aria Operations For Logs port ex. 9000 Default: 80 Raise errors that were rescued during HTTP requests? Default: false Simple rate limiting: ignore any records within `ratelimitmsec` since the last one Default: 0 Number of retries Default: 3 http connection ttl for each request Default: 5 SSL verification flag Default: true HTTP scheme (http,https) Default: http Serialization (json) Default: json Keys from log event to rewrite for instance from 'kubernetesnamespace' to 'k8snamespace' tags will be rewritten with substring substitution and applied in the order present in the hash (Hashes enumerate their values in the order that the corresponding keys were inserted see: https://ruby-doc.org/core-2.2.2/Hash.html (default { 'kubernetes':'k8s', 'namespace':'ns', 'labels':'', 'name':'', 'hash':'', 'container':'' })
Project: Vector (Observability and Analysis / Observability)
File: aws_cloudwatch_metrics.md

title: AWS Cloudwatch metrics description: Publish metric events to component_kind: sink layout: component tags: ["aws", "cloudwatch", "component", "sink", "metrics"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Vector (Observability and Analysis / Observability)
File: 2020-04-07-use-external-tagging-for-metrics-serialization.md

date: "2020-07-13" title: "Use external tagging for metrics serialization" description: "We've improved the way we serialize metrics data" authors: ["binarylogic"] hideonrelease_notes: true pr_numbers: [2231] release: "0.9.0" badges: type: "breaking change" We've improved the serialized structure of our metrics events. This change should only affect a very small, and rare, number of users. If you are consuming metrics data from Vector's `console` sink then you'll need to adjust any downstream systems to work with the new structure. For example, previously a counter was serialized like: ```json { "name": "login.count", "timestamp": "2019-11-01T21:15:47+00:00", "kind": "absolute", "tags": { "host": "my.host.com" }, "value": { "type": "counter", // <-- metric type "value": 24.2 } } ``` It now serialized like: ```json { "name": "login.count", "timestamp": "2019-11-01T21:15:47+00:00", "kind": "absolute", "tags": { "host": "my.host.com" }, "counter": { // <-- metric type "value": 24.2 } } ``` Upgrading should involve handling changes in any systems that are consuming metrics data from the `console` sink.
Project: Prometheus (Observability and Analysis / Observability)
File: diagram_note.md

The architecture image was drawn on https://app.diagrams.net/. The native draw.io source file is called `architecture.xml`, while `architecture.svg` is its SVG export. To change the architecture diagram, go to https://app.diagrams.net/ and import the XML source file. After making changes to the diagram, export the result as SVG. Update both the source file and the SVG export in this directory.
Project: Checkmk (Observability and Analysis / Observability)
File: 16616.md

key | value | date | 2024-03-15T15:16:28+00:00 version | 2.4.0b1 class | feature edition | cre component | wato level | 1 compatible | yes By default a GUI session is terminated after 90 minutes of inactivity (Configurable via global setting Session management). A user could therefore start a session and e.g. start configuring a complex check and while doing something other (e.g. researching some options) the site could be updated. If the user does not interact with the site in that period the user won't notice that the site was updated. Since updates might change some behaviour the session might not work as intended. Therefore during an update all sessions are now terminated. This will cause users to re-authenticate after a site update.
Project: Opstrace (Observability and Analysis / Observability)
File: 2-proposal.md

name: "\U0001F680 Proposal" about: Propose some new work to be done title: '' labels: proposal assignees: '' :stop_sign: Your issue may already be reported! Please search the open issues before creating a new one. <! Explain the difference in system behavior, ideally from the user's point of view --> <! How has this issue affected you? What are you trying to accomplish? --> <! Providing context helps us come up with a solution that is most useful in the real world --> <! Not obligatory, but suggest an idea of how to implement the proposed behavior --> <! Not obligatory; what other technical solutions might achieve the proposed behavior -->
Project: Checkmk (Observability and Analysis / Observability)
File: 16587.md

key | value | date | 2024-04-09T11:57:18+00:00 version | 2.4.0b1 class | fix edition | cre component | wato level | 1 compatible | yes Before this Werk it was possible to create auxiliary tags with the same name as a host tag group and vice versa. This Werk adds an additional check when creating such elements, both in WATO and in the REST API.
Project: Elastic (Observability and Analysis / Observability)
File: to_datetime.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 date value. A string will only be successfully converted if it's respecting the format `yyyy-MM-dd'T'HH:mm:ss.SSS'Z'`. To convert dates in other formats, use <<esql-date_parse>>. ``` ROW string = ["1953-09-02T00:00:00.000Z", "1964-06-02T00:00:00.000Z", "1964-06-02 00:00:00"] | EVAL datetime = TO_DATETIME(string) ```
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: network_chaos.md

Scenario to introduce network latency, packet loss, and bandwidth restriction in the Node's host network interface. The purpose of this scenario is to observe faults caused by random variations in the network. ``` network_chaos: # Scenario to create an outage by simulating random variations in the network. duration: 300 # In seconds - duration network chaos will be applied. node_name: # Comma separated node names on which scenario has to be injected. labelselector: node-role.kubernetes.io/master # When nodename is not specified, a node with matching label_selector is selected for running the scenario. instance_count: 1 # Number of nodes in which to execute network chaos. interfaces: # List of interface on which to apply the network restriction. "ens5" # Interface name would be the Kernel host network interface name. execution: serial|parallel # Execute each of the egress options as a single scenario(parallel) or as separate scenario(serial). egress: latency: 500ms loss: 50% # percentage bandwidth: 10mbit ``` ''' id: network_chaos config: nodeinterfacename: # Dictionary with key as node name(s) and value as a list of its interfaces to test ip-10-0-128-153.us-west-2.compute.internal: ens5 genevsys6081 labelselector: node-role.kubernetes.io/master # When nodeinterfacename is not specified, nodes with matching labelselector is selected for node chaos scenario injection instance_count: 1 # Number of nodes to perform action/select that match the label selector kubeconfig_path: ~/.kube/config # Path to kubernetes config file. If not specified, it defaults to ~/.kube/config execution_type: parallel # Execute each of the ingress options as a single scenario(parallel) or as separate scenario(serial). network_params: latency: 500ms loss: '50%' bandwidth: 10mbit wait_duration: 120 test_duration: 60 ''' Note: For ingress traffic shaping, ensure that your node doesn't have any interfaces already present. The scenario relies on creating IFBs to do the shaping, and they are deleted at the end of the scenario. Pick the nodes to introduce the network anomaly either from nodename or labelselector. Verify interface list in one of the nodes or use the interface with a default route, as test interface, if no interface is specified by the user. Set traffic shaping config on node's interface using tc and netem. Wait for the duration time. Remove traffic shaping config on node's interface. Remove the job that spawned the pod.
Project: Netdata (Observability and Analysis / Observability)
File: ping_packet_loss.md

This alert calculates the `ping packet loss` percentage to the network host over the last 10 minutes. If you receive this alert, it means that your network is experiencing increased packet loss. Ping is a command used to test the reachability of a host on a network. It measures the round-trip-time (RTT) for packets sent from the source host to the destination host. Packet loss occurs when these packets are not successfully delivered to their destination. Check for network congestion: Excessive network traffic can cause packet loss. Use tools like `iftop`, `nload`, or `bmon` to monitor your network bandwidth usage and identify possible congestion sources. Inspect the network hardware: Faulty network hardware like routers, switches, and cables can lead to packet loss. Examine the physical network hardware for possible issues and ensure that all devices are functioning properly. Test the connection to the destination host: Use the `ping` command to test the connection to the destination host: ``` ping <destination_host> ``` If you experience consistent packet loss, it may indicate an issue with the destination host or the network path leading to it. Check the destination host: If the destination host is under heavy load or experiencing issues, it may cause packet loss. Check the host's resources, such as CPU usage, memory usage, and disk space, and resolve any issues if necessary. Investigate possible packet loss causes: Some factors that can cause packet loss include network congestion, poor network equipment performance, corrupt data packets, or interference from other devices. Analyze your network traffic and pinpoint the cause of the packet loss. Rectify any identified issues: Once you've identified the cause of the packet loss, take appropriate measures to resolve it. This may involve updating network hardware, optimizing network traffic, or fixing issues with the destination host.