splunk-sdk-python

Splunk SDK for Python (splunklib) is Splunk’s officially maintained client library for programmatically interacting with a Splunk Enterprise or Splunk Cloud instance. It wraps the low-level splunklib.binding HTTP layer in a Pythonic client.Service object that exposes apps, indexes, saved searches, jobs, and other Splunk resources as ordinary Python collections and entities, so developers can authenticate, run searches, and manage configuration without hand-crafting REST calls.

Beyond the core client, the SDK ships dedicated modules for building Splunk apps: searchcommands for writing custom streaming, generating, reporting, and eventing search commands, and modularinput for building modular input scripts that stream events into Splunk. A newer splunklib.ai package adds scaffolding for wiring LLM-backed agents and tools into Splunk apps. The project is actively maintained by Splunk with regular releases, a Docker-based integration test suite, and requires Python 3.13+.

What You Get

• A client.Service object with fields for apps, jobs, saved searches, indexes, and other Splunk resources exposed as Collection/Entity objects
• Username/password, bearer token, and session-key authentication via client.connect
• searchcommands base classes (StreamingCommand, GeneratingCommand, ReportingCommand, EventingCommand) for writing custom search commands
• modularinput classes (Script, InputDefinition, EventWriter) for building modular input apps that stream external data into Splunk
• An splunklib.ai package for wiring LLM agents, tools, and providers (OpenAI, Anthropic, Google) into Splunk apps
• Configurable logging via setup_logging() and a low-level binding module for direct REST access when the higher-level client isn’t enough

Common Use Cases

• Running one-shot or saved searches against a Splunk instance from a Python script or service
• Writing a custom search command (streaming, generating, or reporting) that extends Splunk’s SPL
• Building a modular input that pulls data from an external system and streams it into Splunk as events
• Managing Splunk configuration objects — apps, indexes, users, saved searches — programmatically as part of deployment automation
• Adding AI/LLM-backed agents and custom tools to a Splunk app via the splunklib.ai package

Under The Hood

Architecture The SDK is layered: splunklib.binding owns the raw HTTP/REST wire protocol (URL construction, XML/Atom response parsing, session handling), and splunklib.client wraps it in a Pythonic domain model — a top-level Service object exposes Collection fields (apps, jobs, indexes, saved searches, inputs) whose members are Entity objects with attribute-style access and fluent update methods. The design deliberately avoids caching resource state, pushing that policy up to the caller. On top of this core sit two purpose-built extension surfaces: searchcommands (base classes like StreamingCommand/GeneratingCommand that Splunk invokes as external search commands) and modularinput (Script/InputDefinition/EventWriter for long-running data-ingestion scripts), both of which hook into the same Service object for instance metadata. A newer splunklib.ai subpackage layers agent/tool/middleware abstractions on top for LLM integrations, kept structurally separate from the core REST client.

Tech Stack Core splunklib has zero runtime dependencies (dependencies = [] in pyproject.toml), keeping the base install minimal; optional extras add six for compatibility and, for splunklib.ai, httpx, langchain, mcp, and pydantic, with provider-specific extras (langchain-anthropic, langchain-openai, langchain-google-genai). The project targets Python 3.13+, is packaged with setuptools via pyproject.toml, and uses uv for dependency management and dev workflows (make uv-sync). Integration tests spin up a real Splunk instance via Docker Compose (compose.yml), and CI runs through GitHub Actions.

Code Quality The repo separates tests/unit, tests/integration, and tests/system suites, run via pytest with pytest-cov and pytest-asyncio, plus vcrpy for HTTP fixture recording in the AI test suite. Linting is enforced with ruff and type-checking with basedpyright, both wired into CI, alongside mbake for Makefile linting and zizmor for workflow security scanning. Integration tests require a live, disposable Splunk Docker container, so day-to-day contributors typically rely on the unit suite. Naming and module boundaries are consistent with the layered architecture (binding vs. client vs. extension modules).

API Design The public surface favors familiar Python idioms — client.connect() returns a Service you index and iterate like a dict/list-backed object (service.apps["my_app"]), and the search-command/modular-input base classes use method overriding (generate/stream/reduce, stream_events) rather than requiring boilerplate registration. Getting started is a single connect() call plus username/password or token; the tradeoff is that deeper features (custom search commands, modular inputs) require understanding Splunk’s own app/package conventions, not just the Python API.