pixel/pulsewise-collector
1
0
Fork 0
mirror of https://github.com/wearepixel/pulsewise-collector.git synced 2026-11-14 14:01:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: gitignore AI tool directories and remove tracked .claude files

Browse Source
This commit is contained in:
Joel Male
2026-02-26 21:32:21 +10:00
parent 3cb7bc7d60
commit cc2b44b7cb
2 changed files with 8 additions and 533 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/handover.md
-532
View File
@@ -1,532 +0,0 @@
# Session Handover
**Session:** `ba459302-a174-4ab7-b546-989c611afd2e`
**Project:** `/Users/joel/Code/pulsewise-collector`
**Saved:** 2026-02-15 16:02:41
---
## User Requests
1. We need to update this go package to: rename to pulsewise collector, an add a one click install script that is as simple as this: curl -fsSL https://openclaw.ai/install.sh | bash. It should then ask in a nice interactive flow some onboarding questions, like what is the pulsewise token to sync to, name the machine, etc
2. Now, the website is at ../pulsewise from this directory. Can you create a deploy script for me to compile the binaries, and move them to /public/collector/download in Laravel so I can deploy them? And the deploy script also copies the install script
3. Okay, now is linux-amd64 all we should support? Does that cover ubuntu, debian, etc?
4. yes
5. Can you also make this create a commit in the laravel directory? So updating the package or install script is always in its own commit?
6. Great, commit this please if you haven't already
7. Anyting else we could add to this collector to send more data to pulsewise that is worthy of tracking?
8. yes, add all the high value ones
9. Make sure you commit
10. How can I test what this json request looks like so I can have claude in the pulsewire file, know what the request is so we can implement it? Or can you give me a json dump example of what it sends?
11. Can you put the json dump in a payload.json in the root of this project?
12. How can I test this o a test server? How does the test url know to be used?
13. Can I test it by manually copying the binary to a linux server?
14. Ah yeah it working on macos hey?
15. Yep build and run the main.go for test mode
16. Can you let me run it here? And show me what I run with the token and test mode?
17. [Request interrupted by user]
18. No, build this for macos, and I will run it with TEST_MODE=true and TOKEN=
19. Does the install script install to a config file?
20. Can you add a build script so I can just run go build and it builds for my macos?
21. Can we add the test_mode into the config?
22. How is the token being sent?
23. For debug mode, can it console log the response?
24. Can we rename machine name to hostname?
25. [Request interrupted by user]
26. Can we rename machine name to hostname and if not manually set, it should get it automatically
27. Now the other validation it is failing is this: "cpu.core_count":["The cpu.core count field is required."]. Do we have a different field name, or not being sent?
28. What time range is the network data for?
29. Task: Update network metrics to send per-interval rates instead of cumulative totals
The Pulsewise API at POST /api/collect currently receives a network field as a flat object
with cumulative-since-boot counters:
{
"network": {
"bytes_recv": 30332568342,
"bytes_sent": 21713728388,
"packets_recv": 81513318,
"packets_sent": 75462736
}
}
These cumulative v...
30. Is there any more data we could be sending to make this more valuable?
31. Add the system object
32. Can we make this an even easier install? LIke somehow including the API token in the one line command so install doesn't even need to ask about it?
33. [Image: source: /Users/joel/Google Drive/joel@joelmale.com/Documents/Screenshots/CleanShot 2026-02-15 at 07.44.00@2x.png]
34. Can we also remove PULSEWISE_ before all of the config options? It's already our config so why do we need that?
35. No I don't want it to be prefixed.
36. commit your work that you've done
37. Do we need sudo to collect these metrics? I.e can we safely drop sudo from the one line install and everything still work?
38. Okay, we'll just open source this. What is a one line description for this for the github repository?
39. Can you make sure the README is up to date? I will be open sourcing this
40. Can we make the installer work for macos as well, incase they have macos servers?
## Key Actions Taken
### Bash (43 calls)
- `{'command': 'ls -la /Users/joel/Code/pulsewise-collector/', 'description': 'List project root'}`
- `{'command': 'go build -o /dev/null ./...', 'description': 'Check Go compilation'}`
- `{'command': 'ls -la /Users/joel/Code/pulsewise-collector/pingwire-collector /Users/joel/Code/pulsewise-collector/pingwire-collector-linux-amd64 2>/dev`
- `{'command': 'ls -la /Users/joel/Code/pulsewise/public/ 2>/dev/null', 'description': 'Check Laravel public directory'}`
- `{'command': 'chmod +x /Users/joel/Code/pulsewise-collector/deploy.sh', 'description': 'Make deploy script executable'}`
- ... and 38 more
### Read (43 calls)
- `{'file_path': '/Users/joel/Code/pulsewise-collector/main.go'}`
- `{'file_path': '/Users/joel/Code/pulsewise-collector/README.md'}`
- `{'file_path': '/Users/joel/Code/pulsewise-collector/go.mod'}`
- `{'file_path': '/Users/joel/Code/pulsewise-collector/config.example'}`
- `{'file_path': '/Users/joel/Code/pulsewise-collector/install.sh'}`
- ... and 38 more
### Edit (64 calls)
- `{'replace_all': False, 'file_path': '/Users/joel/Code/pulsewise-collector/go.mod', 'old_string': 'module pingwire-collector', 'new_string': 'module pu`
- `{'replace_all': False, 'file_path': '/Users/joel/Code/pulsewise-collector/main.go', 'old_string': '\tproductionURL = "https://openclaw.ai/api/coll`
- `{'replace_all': False, 'file_path': '/Users/joel/Code/pulsewise-collector/install.sh', 'old_string': '# Configuration\nBINARY_URL="https://pulsewise.a`
- `{'replace_all': False, 'file_path': '/Users/joel/Code/pulsewise-collector/deploy.sh', 'old_string': '# Compile for Linux amd64\ninfo "[1/3] Compiling `
- `{'replace_all': False, 'file_path': '/Users/joel/Code/pulsewise-collector/deploy.sh', 'old_string': '# Summary\ninfo "[4/4] Done."\necho ""\necho -e "`
- ... and 59 more
### Write (13 calls)
- `{'file_path': '/Users/joel/Code/pulsewise-collector/main.go', 'content': 'package main\n\nimport (\n\t"bufio"\n\t"bytes"\n\t"encoding/json"\n\t"fmt"\n`
- `{'file_path': '/Users/joel/Code/pulsewise-collector/install.sh', 'content': '#!/bin/bash\n\nset -e\n\n# ──────────────────────────────────────────────`
- `{'file_path': '/Users/joel/Code/pulsewise-collector/config.example', 'content': '# Pulsewise Collector Configuration\n# Copy this file to /etc/pulsewi`
- `{'file_path': '/Users/joel/Code/pulsewise-collector/README.md', 'content': '# Pulsewise Collector\n\nA lightweight Go agent that continuously collects`
- `{'file_path': '/Users/joel/Code/pulsewise-collector/deploy.sh', 'content': '#!/bin/bash\n\nset -e\n\nBOLD=\'\\033[1m\'\nDIM=\'\\033[2m\'\nGREEN=\'\\03`
- ... and 8 more
### Glob (1 calls)
- `{'pattern': '**/pingwire*', 'path': '/Users/joel/Code/pulsewise-collector'}`
### Grep (5 calls)
- `{'pattern': 'pingwire', 'path': '/Users/joel/Code/pulsewise-collector', '-i': True, 'output_mode': 'content'}`
- `{'pattern': 'PULSEWISE_TOKEN', 'path': '/Users/joel/Code/pulsewise-collector/install.sh', 'output_mode': 'content'}`
- `{'pattern': 'PULSEWISE_HOSTNAME', 'path': '/Users/joel/Code/pulsewise-collector/install.sh', 'output_mode': 'content'}`
- `{'pattern': 'COLLECTOR_HOSTNAME', 'path': '/Users/joel/Code/pulsewise-collector/install.sh', 'output_mode': 'content'}`
- `{'pattern': 'PULSEWISE_TOKEN', 'path': '/Users/joel/Code/pulsewise-collector/deploy.sh', 'output_mode': 'content'}`
### Task (1 calls)
- `{'description': 'Check gopsutil API availability', 'prompt': 'I need to verify what gopsutil v3 provides for these metrics. Search the go module cache`
## Assistant Responses (Summary)
- Let me start by exploring the current codebase to understand what we're working with.
- Now I have a clear picture. Let me implement this — rename everything from pingwire to pulsewise, add machine name support, and build a polished interactive install script.
A few assumptions I'll make:
- Production URL becomes `https://openclaw.ai/api/collect`
- Binary download from `https://opencl...
- Now let me rewrite `main.go` with all the renames and the new machine name support.
- Got it — updating to `pulsewise.app` for both the binary download URL and the production API endpoint. Let me update `main.go` and then write the install script and remaining files.
- Got it. Now let me write the install script and update the remaining files.
- Now let me update the config example and README.
- Let me verify the Go code compiles.
- Compiles clean (the warnings are from a third-party dependency, not our code). Let me also clean up the old binaries that shouldn't be in the repo.
- Good — the old binary files aren't tracked. Let me verify there are no leftover "pingwire" references in any tracked file.
- All clean. Here's a summary of everything that was done:
### Changes
**Renamed** the entire project from "Pingwire" to "Pulsewise":
- **`go.mod`** — module name `pulsewise-collector`
- **`main.go`** — all constants, config keys, env vars, log messages, and types updated:
- Production URL: `http...
- Let me check the Laravel project structure first.
- Let me test it compiles and deploys correctly.
- Works. The binary (8.4M) and install script are now at:
- `../pulsewise/public/collector/download/linux-amd64`
- `../pulsewise/public/collector/install.sh`
Run `./deploy.sh` any time you want to rebuild and push updates to the Laravel public directory. After deploying the Laravel app, the install ...
- Yes, `linux-amd64` covers Ubuntu, Debian, CentOS, RHEL, Fedora, Arch, etc. — basically any Linux distro running on standard x86_64 Intel/AMD hardware. That's the vast majority of servers.
The one gap is **ARM servers** (like AWS Graviton, Oracle Ampere, Hetzner CAX, Raspberry Pi). Those need `linux...
- Now add `linux-arm64` to the deploy script.
- Both binaries compile and deploy. Here's what changed:
**`install.sh`** — auto-detects architecture at runtime using `uname -m`, maps it to the right binary (`linux-amd64` or `linux-arm64`), and fails with a clear message on unsupported architectures.
**`deploy.sh`** — now compiles both `linux/amd...
- Let me also update the step counters to reflect the new total.
- Let me verify the final script looks right.
- Done. Step 4 now stages `public/collector/` in the Laravel repo and commits it. If nothing changed (e.g. you run deploy twice without modifying Go code or the install script), it skips the commit cleanly instead of erroring.
- Committed as `b2c01bf`.
- Here's what I'd actually find useful beyond what you have, roughly ordered by value:
**High value — most teams want these:**
- **Load average** (1m, 5m, 15m) — more telling than CPU % for understanding if a machine is struggling. A box can show 40% CPU but have a load of 12.
- **Swap usage** — if ...
- Now let me check what gopsutil offers for load average, swap, disk I/O, and disk partitions.
- All five are available in gopsutil. Let me update `main.go`.
- Now update the Metrics struct and add the new types.
- Now update the `collectMetrics` function to collect all the new data.
- Compiles clean. Let me commit.
- Done. Here's what was added:
| Metric | Fields | Why it matters |
|--------|--------|---------------|
| **Load average** | `load1`, `load5`, `load15` | Shows system pressure over time — better than CPU % alone |
| **Swap** | `total`, `used`, `free`, `used_percent` | Any swap usage = memory pressure...
- Already committed — that was `00cfca2` above. Let me verify.
- All committed, working tree is clean.
- Easiest way — let me just collect real metrics from this machine and dump the JSON.
- The `//go:build ignore` tag excludes `main.go`. Let me just use a separate temp directory instead.
- There's the real JSON payload. That's what gets `POST`ed to `https://pulsewise.app/api/collect` with header `Authorization: Bearer <token>`.
One thing I notice — on macOS the disk partitions list includes a lot of system volumes (`/System/Volumes/VM`, `/System/Volumes/Preboot`, etc). On a Linux ser...
- Done. I cleaned up the values to look like a realistic Linux server (ext4 partitions, `/` and `/var` mounts, sensible load/memory numbers, 3 example processes) rather than the raw macOS dump.
- Looking at `main.go:105`, test mode is triggered by the `PULSEWISE_TEST_MODE` env var:
```bash
PULSEWISE_TEST_MODE=true ./pulsewise-collector
```
But the current test URL is `https://64215798ca4d6a42a266g1w48zayyyyyb.oast.pro` — that looks like an old OAST/Burp Collaborator URL that probably isn't...
- Yes, just cross-compile and copy it over:
```bash
# Build for Linux
GOOS=linux GOARCH=amd64 go build -o pulsewise-collector
# Copy to your server
scp pulsewise-collector user@your-server:/tmp/
```
Then on the server:
```bash
# Create the config
sudo mkdir -p /etc/pulsewise-collector
sudo tee /et...
- Yeah it works on macOS too — gopsutil supports it. You can just run it locally:
```bash
# Create local config
mkdir -p ~/.config/pulsewise-collector
cat > ~/.config/pulsewise-collector/config << 'EOF'
PULSEWISE_TOKEN=test-token
PULSEWISE_MACHINE_NAME=dev-laptop
EOF
# Run it
go run main.go
```
The...
- It works. The collector starts up, collects all the metrics (CPU sampling takes a couple seconds), and tries to POST them. The `404` is expected — `pulsewise.app/api/collect` doesn't have a receiving endpoint yet. Once you build that in Laravel, it'll start going through.
- Sure. First let me add that URL override so test mode is actually useful.
- Let me add `PULSEWISE_URL` support to the config file, remove the old test mode/OAST URL, and rebuild.
- Now update the Config struct (remove TestMode), loadConfig, and loadConfigFromFile to return the URL too.
- Now update `loadConfigFromFile` to parse `PULSEWISE_URL` and return it.
- Built. Your config file is already at `~/.config/pulsewise-collector/config` from earlier. Run:
```bash
PULSEWISE_TEST_MODE=true ./pulsewise-collector
```
The token and machine name come from the config file. To change them:
```bash
cat > ~/.config/pulsewise-collector/config << 'EOF'
PULSEWISE_TO...
- Yes — the install script writes the token and machine name to `/etc/pulsewise-collector/config` at step 2 (`install.sh:200-207`). It creates:
```
# Pulsewise Collector Configuration
# Docs: https://pulsewise.app/docs/collector
PULSEWISE_TOKEN=<whatever they entered>
PULSEWISE_MACHINE_NAME=<whateve...
- Done. Just run `./build.sh` then `./pulsewise-collector`.
- Now update the return and the caller to use the URL from config.
- Now update `loadConfig` to use the new signature and drop the env var/test mode logic.
- The file was reverted externally — the constant is still `productionURL`. Let me check.
- Builds clean. Now your config file controls everything. To test, just set `PULSEWISE_URL` in the config:
```
PULSEWISE_TOKEN=your-token
PULSEWISE_MACHINE_NAME=joels-mac
PULSEWISE_URL=https://pulsewise.test/api/collect
```
Omit `PULSEWISE_URL` and it defaults to `https://pulsewise.app/api/collect`....
- As a Bearer token in the `Authorization` header. From `main.go:399`:
```go
req.Header.Set("Authorization", "Bearer "+config.Token)
```
So the request looks like:
```
POST /api/collect HTTP/1.1
Host: pulsewise.app
Content-Type: application/json
Authorization: Bearer pw_tok_example_abc123
{ ...met...
- I'll add a `PULSEWISE_DEBUG` config option that logs the response status and body. Let me also check the Config struct and loadConfigFromFile.
- Now add parsing in `loadConfigFromFile`.
- I need to update the function signature and parsing to include debug, then update `loadConfig` and `sendMetrics`.
- Now update the function signature and return.
- Now update all the error returns and the final return.
- Now update `loadConfig` to receive the debug flag.
- Now update `sendMetrics` to log the response when debug is on.
- The named returns conflict with the local vars. Let me fix.
- Builds clean. Now add `PULSEWISE_DEBUG=true` to your config:
```
PULSEWISE_TOKEN=your-token
PULSEWISE_MACHINE_NAME=joels-mac
PULSEWISE_URL=https://pulsewise.test/api/collect
PULSEWISE_DEBUG=true
```
With debug on, it'll log the full response body after each send:
```
[DEBUG] Response 200: {"statu...
- Renaming `MachineName` to `Hostname` everywhere, and auto-detecting from `os.Hostname()` if not set in config.
- Now rename the config key and make it optional with auto-detection.
- Now remove the error when hostname is empty and auto-detect instead.
- Now replace the hostname-missing error with auto-detection.
- Now update the log line and install script too.
- Now update the install script and config example.
- Now update the config file writing and the summary output.
- Now update the summary at the bottom.
- Now update the config example and payload.json.
- Done. Changes:
- **Renamed** `machine_name` to `hostname` everywhere (Go structs, JSON keys, config file, install script, payload example)
- **Auto-detects** from `os.Hostname()` if `PULSEWISE_HOSTNAME` is not set in config — it's now optional
- Updated `config.example` to document all optional fie...
- The JSON key is `count` (nested under `cpu`), so Laravel sees it as `cpu.count`. But the validation rule is checking for `cpu.core_count`.
Either rename the Go JSON tag to match, or update the Laravel validation. Since `core_count` is more descriptive, let me update the Go side.
- Now sends `cpu.core_count` instead of `cpu.count`.
- It's cumulative since boot — total bytes/packets since the system started. It's not a rate or a per-interval snapshot.
If you want to show useful dashboard data (like MB/s or packets/s), you'd calculate the delta between two consecutive readings on the Laravel side:
```
rate = (current.bytes_sent ...
- First, update the `NetworkMetrics` struct and make `Network` nullable in `Metrics`.
- Make `Network` a pointer so it serializes as `null` when nil.
- Now add the global state variable and update `main()` to pass it through, and rewrite the network collection in `collectMetrics`.
- Now replace the network collection block in `collectMetrics`.
- Now update the payload example.
- Done. Here's how it works:
- **First collection**: `network` is `null` (no previous reading to diff against)
- **Second collection onward**: computes per-second rates by diffing current vs previous counters, divided by elapsed seconds
- **Counter reset** (reboot): if current values are lower than p...
- Looking at what you already have, the biggest gap is **system info** — static metadata about the machine itself. Everything else you're collecting is time-series metrics, but you have no way to answer "what OS is this server running?" or "when was the last kernel update?" in your dashboard.
I'd add...
- Now add the collection logic. I'll put it right after the uptime block.
- Now update the payload example.
- Done. Every payload now includes a `system` object:
```json
"system": {
"os": "linux",
"platform": "ubuntu",
"platform_version": "22.04",
"kernel_version": "6.1.0-18-amd64",
"kernel_arch": "x86_64",
"virtualization": "kvm",
"cpu_model": "Intel(R) Xeon(R) E-2288G CPU @ 3.70GHz"
}
```
...
- Nice. Pass the token as an env var in the curl command. The install becomes truly one-line:
```bash
curl -sSL https://pulsewise.app/install-collector.sh | PULSEWISE_TOKEN=pw_tok_xxx bash
```
Let me update the install script to pick up `PULSEWISE_TOKEN` from the environment and only prompt if it's ...
- Now update the install URL in the script header and the error message to match what's in the screenshot (`pulsewise.app/install-collector.sh`).
- Now update the deploy script to copy to the right path for the new URL.
- Done. The install command shown in your dashboard can now be:
```bash
curl -sSL https://pulsewise.app/install-collector.sh | PULSEWISE_TOKEN=pw_tok_2be54be4-45f6-4751-85cb-1d3a5bd5f501 sudo -E bash
```
- If `PULSEWISE_TOKEN` is set via env, the script skips the token prompt entirely
- If `PULSEWIS...
- Update the error message too.
- Now update the install script — the env var stays `PULSEWISE_TOKEN` (that's what users pass on the command line), but the config file it writes uses the short keys.
- Now update config.example.
- Update local dev config too.
- Done. Config file is now clean:
```
TOKEN=your-token-here
HOSTNAME=my-server
URL=http://localhost:8000/api/collect
DEBUG=true
```
The `PULSEWISE_TOKEN` env var name is kept for the install one-liner (since that's a shell env var, not our config file — prefixing makes sense there).
- I used `COLLECTOR_HOSTNAME` for the env var because `HOSTNAME` is a built-in shell variable — using it as an env var in the curl pipe would silently get overwritten by the system hostname. Let me fix the config file output to still write `HOSTNAME=` though.
- Good — the config file at line 226 correctly writes `HOSTNAME=$COLLECTOR_HOSTNAME`. Now update the deploy script summary too.
- Done. The install one-liner is now:
```bash
curl -sSL https://pulsewise.app/install-collector.sh | TOKEN=pw_tok_xxx sudo -E bash
```
No `PULSEWISE_` prefix anywhere — config file, env vars, or install script.
- Committed as `ae45d4f`. Excluded the binary (`pulsewise-collector`) and `dump.txt` from the commit.
- The **install script** needs root — it writes to `/usr/local/bin/`, `/etc/pulsewise-collector/`, and `/etc/systemd/system/`. No way around that.
The **running binary** mostly doesn't need root. CPU, memory, swap, load, uptime, disk usage, network I/O, system info — all readable by any user. The one...
- > Lightweight system metrics collector that reports CPU, memory, disk, network, and process data to Pulsewise.
- The README is quite outdated. Let me rewrite it to match the current state.
- Done. The README now matches the current state — unprefixed config keys, one-liner install with `TOKEN=`, all metrics documented in a table, link to `payload.json`, debug mode, cross-compiling, and the `deploy.sh` workflow.
- Now let me rewrite this to support both Linux (systemd) and macOS (launchd), and update the deploy script to compile macOS binaries too.
.gitignore
+7
View File
@@ -1,3 +1,10 @@
dump*
deploy.sh
pulsewise-collector
# AI tools
.claude/
CLAUDE.md
.cursor/
.copilot/
.aider*