Token导航 LogoToken导航

Agent Skill · 研究检索

log-analyzer(日志分析器)

log-analyzer 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

log-analyzer 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证信息还不明确,第三方扫描已通过,按安装量在研究检索类的 73,675 个 Skill 里排第 52,782。

总安装 546周安装 23GitHub Stars 527下载 191核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:log-analyzer(日志分析器)
来源仓库:https://github.com/mikopbx/core
仓库路径:skills/log-analyzer
安装命令:
npx skills add https://github.com/mikopbx/core --skill log-analyzer
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/mikopbx/core --skill log-analyzer

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

log-analyzer 用于查找、检索和筛选相关信息。适合在 Codex、Claude、Cursor、Gemini CLI 中根据关键词快速定位候选结果。通过 npx skills add 命令从指定仓库安装,需确认权限和维护状态。使用前建议核实是否会触发联网、命令执行或文件读写操作。

适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/log-analyzer

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/mikopbx/core --skill log-analyzer;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

log-analyzer 怎么安装?

在终端执行 npx skills add https://github.com/mikopbx/core --skill log-analyzer。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

log-analyzer 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

log-analyzer 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

log-analyzer 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

log-analyzer 用的人多吗?

公开数据是累计安装 546 次,近一周安装 23 次,下载 191 次,GitHub 527 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

log-analyzer 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
log-analyzer

日志分析器 · 本页

546527需要联网未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

MikoPBX Log Analyzing

Efficiently analyze logs inside MikoPBX Docker container to diagnose issues, monitor processes, and track system behavior.

What This Skill Does

  • Intelligently searches logs based on problem context
  • Identifies relevant log files for each issue type
  • Filters noise to show only relevant entries
  • Correlates logs across multiple files
  • Tracks worker processes and their status
  • Provides actionable insights from log analysis
  • Works with both host-mounted logs and docker exec for flexibility

Host Log Access (Faster)

For local development, logs are mounted on the host at:

/Users/nb/PhpstormProjects/mikopbx/dev_docker/tmp/projects/main/storage/usbdisk1/mikopbx/log/

Advantages of host access:

  • ✅ Faster (no docker exec overhead)
  • ✅ Can use Read tool directly
  • ✅ Can use Grep tool with full power
  • ✅ Better for large log files

When to use host path:

  • Analyzing large log files
  • Complex grep patterns
  • Multiple log file analysis
  • Performance-critical operations

When to Use This Skill

Use this skill when:

  • User reports an error or issue
  • Need to diagnose API problems
  • Tracking specific worker processes
  • Investigating system behavior
  • User asks "check logs" or "what's in the logs?"
  • After tests fail (to find root cause)
  • Monitoring real-time system activity

Quick Start

Step 1: Choose Access Method

Option A: Host Path (Recommended for analysis)

# Direct access to logs (faster)
HOST_LOG_PATH="/Users/nb/PhpstormProjects/mikopbx/dev_docker/tmp/projects/main/storage/usbdisk1/mikopbx/log"

# Use Grep tool
# Pattern: errors in system log
# Path: $HOST_LOG_PATH/system/messages

# Or use Read tool for specific log files

Option B: Docker Exec (Needed for process checks)

# Find MikoPBX container (needed for worker checks)
CONTAINER_ID=$(docker ps | grep mikopbx | awk '{print $1}' | head -1)

Quick Decision Guide:

  • Log file analysis → Use host path with Grep/Read tools
  • Process/worker checks → Use docker exec with Bash
  • Real-time monitoring → Use docker exec with tail -f

Step 2: Determine Log Context

Based on issue type, select appropriate logs:

API Issues:

  • System messages (WorkerApiCommands)
  • PHP error log
  • Nginx logs

Call Issues:

  • Asterisk messages/error/verbose
  • Security log

Database Issues:

  • System messages
  • Debug query logs (if enabled)

Worker Issues:

  • System messages (filter by worker name)
  • Process status

Step 3: Execute Analysis

Use targeted search patterns (see search-patterns.md):

# Recent errors
docker exec $CONTAINER_ID tail -500 /storage/usbdisk1/mikopbx/log/system/messages | grep -i error

# Specific worker
docker exec $CONTAINER_ID tail -300 /storage/usbdisk1/mikopbx/log/system/messages | grep WorkerApiCommands

# Real-time monitoring
docker exec $CONTAINER_ID tail -f /storage/usbdisk1/mikopbx/log/system/messages

Top 5 Common Verification Patterns

Pattern 1: Recent System Errors

When to use: First step in diagnosing any issue

Method A: Host Path (Recommended)

# Use Grep tool
# Pattern: error
# Path: /Users/nb/PhpstormProjects/mikopbx/dev_docker/tmp/projects/main/storage/usbdisk1/mikopbx/log/system/messages
# Options: -i (case insensitive), -C 2 (2 lines context)

Method B: Docker Exec

# Get last 500 lines, filter errors
docker exec $CONTAINER_ID tail -500 /storage/usbdisk1/mikopbx/log/system/messages | grep -i error

What to look for:

  • Error timestamps (correlation)
  • Error frequency (isolated vs recurring)
  • Component name (which part failed)
  • PID (which process)

Common findings:

  • PHP fatal errors
  • Database constraint violations
  • Worker crashes
  • Memory exhaustion

Pattern 2: API Request Debugging

When to use: API request fails or returns unexpected result

Method A: Host Path (Recommended)

# Use Grep tool for WorkerApiCommands activity
# Pattern: WorkerApiCommands
# Path: /Users/nb/PhpstormProjects/mikopbx/dev_docker/tmp/projects/main/storage/usbdisk1/mikopbx/log/system/messages

# Use Read tool for PHP errors (recent)
# Path: /Users/nb/PhpstormProjects/mikopbx/dev_docker/tmp/projects/main/storage/usbdisk1/mikopbx/log/php/error.log
# Offset: calculate from file size
# Limit: 50

# Use Grep for nginx access
# Pattern: POST /pbxcore/api
# Path: /Users/nb/PhpstormProjects/mikopbx/dev_docker/tmp/projects/main/storage/usbdisk1/mikopbx/log/nginx/access.log

Method B: Docker Exec

# Check WorkerApiCommands activity
docker exec $CONTAINER_ID tail -200 /storage/usbdisk1/mikopbx/log/system/messages | grep WorkerApiCommands

# Check PHP errors
docker exec $CONTAINER_ID tail -50 /storage/usbdisk1/mikopbx/log/php/error.log

# Check nginx access log
docker exec $CONTAINER_ID tail -100 /storage/usbdisk1/mikopbx/log/nginx/access.log | grep "POST /pbxcore/api"

What to look for:

  1. Request received by nginx
  2. Request queued to Redis
  3. WorkerApiCommands processing
  4. PHP errors during execution
  5. Response status code

Expected flow:

[06:52:10] nginx: POST /pbxcore/api/v3/extensions
[06:52:11] WorkerApiCommands: Processing request
[06:52:12] WorkerApiCommands: Executing SaveRecordAction
[06:52:13] WorkerApiCommands: Response sent (200 OK)

See analysis-scenarios.md for detailed example.


Pattern 3: Worker Process Monitoring

When to use: Worker not responding, system seems stuck

# Check if worker is running
docker exec $CONTAINER_ID ps aux | grep WorkerApiCommands

# Check for crashes
docker exec $CONTAINER_ID tail -500 /storage/usbdisk1/mikopbx/log/system/messages | grep -E "WorkerApiCommands|terminated|crash"

# Count instances
docker exec $CONTAINER_ID ps aux | grep WorkerApiCommands | grep -v grep | wc -l

Expected: WorkerApiCommands should have 3 instances

What to look for:

  • Process terminated messages
  • Orphaned process warnings
  • Fatal PHP errors
  • Last activity before crash

Common issues:

  • Worker crashed (0 instances)
  • Too many workers (restart loop)
  • Zombie processes

See worker-processes.md for complete worker reference.


Pattern 4: Database Error Investigation

When to use: Constraint violations, lock errors, data inconsistency

# Check for database errors
docker exec $CONTAINER_ID tail -200 /storage/usbdisk1/mikopbx/log/system/messages | grep -iE "database|sqlite|constraint"

# Check PHP PDO errors
docker exec $CONTAINER_ID tail -100 /storage/usbdisk1/mikopbx/log/php/error.log | grep -iE "database|pdo|sql"

Common errors:

  • UNIQUE constraint failed: Extensions.number - Duplicate data
  • FOREIGN KEY constraint failed - Invalid reference
  • Database is locked - Concurrent access
  • Database disk image is malformed - Corruption

Investigation steps:

  1. Identify which query failed
  2. Check input data for duplicates/invalids
  3. Verify foreign key references exist
  4. Check for long-running transactions

See analysis-scenarios.md for detailed troubleshooting.


Pattern 5: Real-Time Activity Monitoring

When to use: Need to see what's happening right now

# Follow system log
docker exec $CONTAINER_ID tail -f /storage/usbdisk1/mikopbx/log/system/messages

# Follow with error filter
docker exec $CONTAINER_ID tail -f /storage/usbdisk1/mikopbx/log/system/messages | grep -i error

# Follow specific worker
docker exec $CONTAINER_ID tail -f /storage/usbdisk1/mikopbx/log/system/messages | grep WorkerApiCommands

Use cases:

  • Monitor API request processing
  • Watch worker activity
  • See errors as they occur
  • Debug timing issues

Pro tip: Press Ctrl+C to stop monitoring when done.


Critical Log Files

Host Paths (Fast Access)

# Log base directory on host
HOST_LOG_BASE="/Users/nb/PhpstormProjects/mikopbx/dev_docker/tmp/projects/main/storage/usbdisk1/mikopbx/log"

# PRIMARY: Main system log
${HOST_LOG_BASE}/system/messages

# PHP errors
${HOST_LOG_BASE}/php/error.log

# Asterisk errors
${HOST_LOG_BASE}/asterisk/error

# Web server errors
${HOST_LOG_BASE}/nginx/error.log

# Fail2ban logs
${HOST_LOG_BASE}/fail2ban/fail2ban.log

Container Paths (For docker exec)

# PRIMARY: Main system log
/storage/usbdisk1/mikopbx/log/system/messages

# PHP errors
/storage/usbdisk1/mikopbx/log/php/error.log

# Asterisk errors
/storage/usbdisk1/mikopbx/log/asterisk/error

# Web server errors
/storage/usbdisk1/mikopbx/log/nginx/error.log

Quick Access Commands

Using Host Path (Faster)

# Check recent errors in system log
# Use Grep tool:
#   Pattern: error
#   Path: /Users/nb/PhpstormProjects/mikopbx/dev_docker/tmp/projects/main/storage/usbdisk1/mikopbx/log/system/messages
#   Options: -i -C 2

# Read PHP error log
# Use Read tool:
#   Path: /Users/nb/PhpstormProjects/mikopbx/dev_docker/tmp/projects/main/storage/usbdisk1/mikopbx/log/php/error.log

# Search for specific pattern
# Use Grep tool:
#   Pattern: WorkerApiCommands
#   Path: /Users/nb/PhpstormProjects/mikopbx/dev_docker/tmp/projects/main/storage/usbdisk1/mikopbx/log/system/messages

Using Docker Exec (For processes)

# Find container
docker ps | grep mikopbx

# Tail system log
docker exec <id> tail -100 /storage/usbdisk1/mikopbx/log/system/messages

# Tail errors only
docker exec <id> tail -500 /storage/usbdisk1/mikopbx/log/system/messages | grep -i error

# Check PHP errors
docker exec <id> tail -50 /storage/usbdisk1/mikopbx/log/php/error.log

# Check workers (MUST use docker exec)
docker exec <id> ps aux | grep Worker

Output Format

Always structure log analysis output clearly:

📋 Log Analysis: <Component/Issue>
==================================

🔍 Search Criteria:
   • Log file: /path/to/log
   • Time range: HH:MM - HH:MM
   • Pattern: <search pattern>
   • Lines analyzed: N

📊 Summary:
   • Total lines: N
   • Errors: N
   • Warnings: N

❌ Errors Found (N):

1. [HH:MM:SS] Error Type
   Location: File.php:line
   Message: Error description
   Process: WorkerName[PID]

2. [HH:MM:SS] Error Type
   ...

⚠️  Warnings Found (top 5):

1. [HH:MM:SS] Warning description
2. ...

🔄 Process Status:

WorkerApiCommands:
   ✅ Running (3 instances)
   PIDs: 1637, 1639, 1641

💡 Analysis:

<interpretation of findings>

🎯 Recommendations:

1. Fix X in File.php:line
2. Check Y in database
3. Monitor Z

Additional Resources

Complete References

Practical Examples

Quick References

Log Locations:

/storage/usbdisk1/mikopbx/log/
├── system/messages      # Main system log
├── php/error.log        # PHP errors
├── asterisk/error       # Asterisk errors
├── nginx/error.log      # Web errors
└── fail2ban/fail2ban.log # Security

Common Workers:

  • WorkerApiCommands (3 instances) - API processing
  • WorkerModelsEvents (1) - DB change events
  • WorkerCdr (1) - CDR processing
  • WorkerNotifyByEmail (1) - Email sender

Best Practices

Efficient Analysis

  1. Start broad, then narrow

- Check system log first (overview) - Filter for errors (specific issues) - Check component logs (details)

  1. Use tail with limits

- ✅ tail -500 | grep (fast) - ❌ cat | grep (slow for large files)

  1. Filter aggressively

- Use specific patterns - Combine with grep -E for OR logic - Use grep -v to exclude noise

  1. Check timestamps

- Correlate events by time - Reconstruct event sequence - Find related errors

  1. Monitor processes

- Verify services are running - Check worker counts - Look for zombies/orphans

  1. Look for patterns

- Single error = isolated - Repeated errors = systemic - Use uniq -c to count occurrences

  1. Save findings

- Document errors - Note timestamps - Record context

Performance Considerations

  • Use tail -N instead of cat for large files
  • Pipe through head to limit output
  • Check file sizes before reading entire files (ls -lh)
  • Use -f for real-time monitoring only when needed
  • Kill monitoring processes when done (Ctrl+C)

Troubleshooting Tips

If logs are empty:

  • Check if logging is enabled
  • Verify log file permissions
  • Check if rsyslog is running

If container command fails:

  • Verify container is running: docker ps
  • Check container name/ID
  • Try with docker exec -it for interactive mode

If can't find pattern:

  • Try case-insensitive: -i
  • Try broader pattern: -E "pattern1|pattern2"
  • Increase tail count
  • Check related log files

Integration with Other Skills

With mikopbx-docker-restart-tester:

  1. Restart container
  2. Use this skill to monitor startup
  3. Check for errors during initialization

With mikopbx-api-test-generator:

  1. Generate and run tests
  2. Use this skill to analyze test failures
  3. Find root cause in logs

With mikopbx-endpoint-validator:

  1. Validator finds issue
  2. Use this skill to see actual runtime errors
  3. Correlate validation findings with logs

Common Error Patterns

PHP Errors

  • Fatal error: - PHP crashed, script stopped
  • Undefined variable: - Variable not initialized
  • Call to undefined function: - Missing function
  • UNIQUE constraint failed: - Database duplicate

Worker Errors

  • Process terminated - Worker crashed
  • Orphaned process - Worker parent died
  • Failed to connect - Service unavailable
  • Timeout exceeded - Operation too slow

Asterisk Errors

  • Could not create an object - Config error
  • Error parsing allow= - Codec config issue
  • Authentication failed - Wrong credentials
  • No route to destination - Routing problem

System Errors

  • Out of memory - Memory exhausted
  • Cannot allocate memory - Resources low
  • Too many open files - File descriptor limit
  • Connection refused - Service not running

Success Criteria

Log analysis is successful when:

  • ✅ Root cause identified
  • ✅ Actionable information extracted
  • ✅ Relevant context provided
  • ✅ Next steps clear
  • ✅ No unnecessary noise in output
  • ✅ Findings well-structured and readable

平台分布

Codex

36.22%
按下载量换算69

Claude

29.97%
按下载量换算57

Cursor

19.9%
按下载量换算38

Gemini CLI

9.99%
按下载量换算19

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills