As we start to see big moves from monolith deployments to microservices, the adoption of Kubernetes has become top of mind for many SREs. Organizations can leverage the open-source system to automate deployments, scale, and manage containers, making Kubernetes one of the primary solutions for delivering workloads. However, maintaining the system can be difficult and, in some cases, overwhelming.

Splunk Cloud Architect Paul Davies recently authored and released the GCP Application Template, a blueprint of visualizations, reports, and searches focused on Google Cloud use cases. Many of the reports included in his application require Google Cloud asset inventory data to be periodically generated and sent into Splunk. But HOW exactly do you craft that inventory generation pipeline so you can "light-up" Paul's application dashboards and reports?

Rapid digital transformation partnered with increased cloud adoption have resulted in organizations generating unprecedentedly large volumes of data. This data is stored in disparate data repositories due to organizational boundaries, data protection, and privacy laws (e.g. GDPR). Additionally, it is stored across environment types with some kept in the cloud and often historical data and other sensitive data types are kept in on-premise environments contributing to more data silos.

Today we released API 2.0, the latest version of TruSTAR’s API-First Intelligence Management Platform. This new version continues our commitment to simplify and streamline intelligence for automation in enterprise security intelligence management, and breaks through long-standing industry limitations around operationalizing data orchestration and normalization.

Before apps can be installed in a customer’s Splunk Cloud deployments, these apps have to go through Splunk’s cloud vetting process. Cloud vetting helps ensure that apps are safe and performant for our mutual customers to use in Splunk Cloud. It’s important for us to make regular updates to our cloud vetting requirements in order to ensure apps running on Splunk Cloud are “up to snuff”.

Extended Detection and Response (XDR) has generated a lot of buzz recently with press, analysts, and even customers. There’s no denying that, at face value, its promise of reduced complexity and cost while increasing detection and response is alluring. As security teams look to modernize their security tooling, they’re also looking for solutions to some of their largest challenges. Is XDR the answer? What is XDR, exactly, and how do you determine if it’s right for your organization?

Most front-end developers and practitioners are familiar with real user monitoring (RUM) tools as a means to understand how end-users are perceiving the performance of applications. Few people, however, are aware of the history of the RUM market, going back more than two decades. Over the years, as the internet has evolved with new technologies, RUM tools have evolved in lock-step to cater to the ever changing needs and use cases of engineering teams.