OCI Generative AI offers an on-demand service which you can access from your tenancy and pay only for what you use. This is very handy and also ensure that no data goes outside of the company if you were to copy/paste logs into whatever web based LLM. Integrating that capabilty into your daily hands-on work (analyze system state, diagnose issues, generate code, etc...) without ever leaving the terminal is a real productivity booster.
This is why I have developped a function which wraps the OCI CLI Generative AI Inference service that you can source and then call from the command line. You can download the full script from my GitHub repository.
Note that this is not meant to interact with your system, it cannot access your system.
This is why I have developped a function which wraps the OCI CLI Generative AI Inference service that you can source and then call from the command line. You can download the full script from my GitHub repository.
Note that this is not meant to interact with your system, it cannot access your system.
Prerequisites: OCI Setup
Before using the function, you must have the OCI CLI installed and your OCI API keys configured on your system. If you haven't configured API keys yet, check out my step-by-step guide: OCI: Setting up API Keys.
Prerequisites: Compartment ID
You will need to set up your compartment ID inside the function:
DEF_COMP_ID="xxxxxxxxxx"or export it from the command line before calling the function:
export ENV_COMP_ID="xxxxxxxxxx"You may also adapt to your region:
export DEF_REGION="yyyyyyy"or also export it from the command line before calling the function:
export ENV_REGION="us-phoenix-1"
Source the function and a first use
At the time I am writting this blog (Sep-2026), the function is set to use Grok 4.3 -- which can easily be updated into the function as well.
[frdenis@myvm ~]$ source .ai_functions" [frdenis@myvm ~]$ source .ai_functions" [frdenis@myvm ~]$ ask_llm "who are you ?" I'm Grok, an AI built by xAI. I'm here to answer questions, help with problems, and have a bit of fun while doing it. What's up? [frdenis@myvm ~]$
Storage Pressure Analysis (df)
First example is to check for space pressure on our system by seding the output of
df -hto the LLM:[frdenis@myvm ~]$ ask_llm "has this $(cat /etc/redhat-release) system some space pressure issue ? $(df -h)" Based on the output, **no critical space pressure** at the moment, but there are a couple of areas worth monitoring: ### Summary | Filesystem | Usage | Status | |------------|-------|--------| | `/` (root) | 61% | Moderate – fine for now | | `/boot` | 68% | **Highest %** – monitor for kernel updates | | `/data` | 39% | Healthy | | `/run` (tmpfs) | 9% (4.1G used) | Using **4.1 GB of RAM** – worth checking | ### Recommendations 1. **`/boot` at 68%** This is the most "full" filesystem percentage-wise. If you install new kernels or if old ones aren't cleaned up, you could run into issues during updates. Consider removing old kernels if they're no longer needed. 2. **`/run` tmpfs using 4.1 GB** This is in-memory usage. If your system has memory constraints, investigate what's consuming that space: ```bash du -sh /run/* 2>/dev/null | sort -h ``` Common culprits: large files in `/run/user/*`, container runtime data, or logs written to tmpfs. 3. **Root (`/`) at 61%** Not urgent, but if this system generates a lot of logs or temporary data, keep an eye on it. **Bottom line:** No immediate crisis, but clean up `/boot` and check what's using 4.1 GB in `/run`.
SAR
We can also send the last 7 days of SAR for a quick summary / find potential issues:
[frdenis@myvm ~]$ ask_llm "check if this system has cpu issue, also let me know when are the cpu peaks: $(for i in {1..7}; do sar -u -f /var/log/sa/sa$(date -d "$i days ago" +%d); done)" **Analysis Summary** ### Overall Assessment **No significant CPU issue** on this system. - The system has **16 CPUs** and is very lightly loaded on average. - Average CPU utilization across all days is only **~10-11%** busy (`100% - 89% idle`). - `%iowait` and `%steal` are negligible, which is good. ### CPU Usage Pattern | Metric | Average | Typical Range | Notes | |-----------------|---------|---------------|-------| | **%user** | ~3.9% | 0.3 – 24% | Main driver of spikes | | **%system** | ~6.8% | 6.0 – 8.7% | Stable | | **%idle** | ~89% | 68 – 93% | Very healthy | | **Total busy** | ~11% | - | Low load | ### When CPU Peaks Occur The system shows **very consistent daily patterns**: | Time | Typical Peak | %user | Total Busy | Frequency | Notes | |-------------------|--------------|-------|------------|---------|-------| | **12:00 PM – 12:10 PM** | **Highest** | 18–24% | **~25–31%** | Every day | **Main peak** | | **07:10 AM – 07:20 AM** | High | 10–17% | ~18–25% | Every day | Morning spike | | **11:10 AM, 11:50 AM** | Medium | 8–13% | ~15–20% | Frequent | - | | **02:40 PM – 03:10 PM** | Medium | 7–11% | ~15–20% | Frequent | - | | **02:40 AM – 03:10 AM** | Medium | 7–13% | ~15–22% | Occasional | Night spike | ### Key Observations - **Biggest and most consistent peak**: **12:00 PM – 12:10 PM** every day (reaches ~30% CPU). . . .
A quick shell command
We can also generate some code:
[frdenis@myvm ~]$ ask_llm "bash how to find the top 5 biggest files in my directories ?" Here's the most common and effective way to find the **top 5 largest files** in a directory (including subdirectories): ### From current directory: ```bash find . -type f -exec du -h {} + 2>/dev/null | sort -rh | head -5 ``` ### From root (entire system) — requires `sudo`: ```bash sudo find / -type f -exec du -h {} + 2>/dev/null | sort -rh | head -5 ``` ### Alternative (faster, shows size in bytes): ```bash find . -type f -printf '%s %p\n' | sort -rn | head -5 ``` ### Explanation: | Command part | Purpose | |--------------|--------| | `find . -type f` | Find only files (ignore directories) | | `-exec du -h {} +` | Get human-readable sizes | | `sort -rh` | Sort by size, reverse (largest first), human-readable | | `head -5` | Show only top 5 | ### Tip: If you want to **exclude certain directories** (like `/proc`, `/sys`, etc.), you can do: ```bash sudo find / -path /proc -prune -o -path /sys -prune -o -type f -exec du -h {} + 2>/dev/null | sort -rh | head -5 ```It is also very useful for crash diagnosis using /var/log/messages, etc... possibilities are endless. Test it and enjoy!
