khi-parser

Implements and modifies log parser tasks for Kubernetes History Inspector pipelines.

2.1k|97|Updated Jan 22, 2025
One-click install
npx skills add https://github.com/GoogleCloudPlatform/khi --skill khi-parser-googlecloudplatform
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: khi-parser
Source: https://github.com/GoogleCloudPlatform/khi/tree/main/.agents/skills/khi_parser
Command: npx skills add https://github.com/GoogleCloudPlatform/khi --skill khi-parser-googlecloudplatform

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Adding support for new log types in Kubernetes History Inspector (KHI) requires navigating a strict DAG task architecture with contract/implementation package separation, and mistakes cause circular imports or broken task registration. This Skill provides the exact package patterns, code templates, and testing strategies to implement log parsers correctly. ## Core Features & Use Cases - Package Structure Enforcement: Defines the contract package (taskid.go, extractor.go, timeline_type.go) versus implementation package (impl/ with form.go, query.go, ingester.go, mapper.go, registration.go) boundaries to prevent circular imports. - Complete Pipeline Templates: Provides working Go code for all four DAG steps: form tasks, Cloud Logging query tasks, log ingesters, and timeline mappers, including the advanced ManifestLogToTimelineMapper for multi-resource state tracking. - Testing Strategies: Includes table-driven test patterns for ingesters, mappers, and chronological multi-group merge validation using mock logs and fluent ChangeSet assertions. - Use Case: When you need to add support for a new log source (e.g., a custom application writing to Cloud Logging), follow the step-by-step samples to create the contract package, implement the four pipeline tasks, register them, and write unit tests. ## Quick Start Use the khi-parser skill to add a new log parser for my custom application logs under pkg/task/inspection/googlecloud/customapp.

Frequently Asked Questions about khi-parser

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new log parser to Kubernetes History Inspector?▼

Create a contract package under pkg/task/inspection/<provider>/<feature>/ defining TaskIDs, extractors, and timeline types, then an impl subpackage with form, query, ingester, and mapper tasks. Register all tasks in impl/registration.go via coretask.RegisterTasks.

How do I query logs from Google Cloud Logging in a KHI task?▼

Use gcpcommon.NewListLogEntriesTask with a settings struct implementing TaskID, Dependencies, LogFilters, DefaultResourceNames, and TimePartitionCount. The LogFilters method builds the Cloud Logging filter string from form task parameters.

Why must KHI parser packages separate contract and implementation code?▼

The separation guarantees task IDs are fully initialized before implementation and prevents circular import dependencies. The root contract package must not import impl, and external packages must only import the contract package.

How do I test a LogToTimelineMapper task in KHI?▼

Use table-driven tests that inject a khifilev6.Builder into context via khictx.WithValue, call ProcessLog directly with mock logs from testlog.NewMockLog, and verify output with the fluent testchangeset.AssertTimeline asserter.

When should I use ManifestLogToTimelineMapper instead of a standard mapper?▼

Use it when tracking multiple related resources chronologically, such as a parent Pod and its subresources. It merges logs from multiple roles sorted by timestamp and passes shared state across all events.

Why must FieldPath values be package-level variables in KHI extractors?▼

Pre-compiled structured.FieldPath values are constant across log entries, so compiling them inside functions or hot parsing loops wastes CPU. Declaring them as package-level variables avoids repeated compilation across millions of log entries.