Ask about your systems
Once a system is connected, ask about it the way you would ask a colleague. Verbiqo works out what to look at, measures it, and answers from what it measured.
Start a conversation
Open Explain / Ask
Choose Explain / Ask… from the Verbiqo menu bar icon, with nothing selected.
Attach a system
Type / and pick the system, or type it in full with the name you gave the connection:
/pg orders,/mysql shop,/mssql sales,/redis cache,/es logs,/k8s prod,/prom prod,/splunk prod./security allattaches the security review of every connection.Ask your question
Type it and press Ask.
A question reaches only what is attached. Machine facts for a database (memory, disks, the cluster manager, history) come from a Prometheus source attached in the same conversation, not from one that is merely saved. Type /sources to see what is attached, and /pg off (or /k8s off, /prom off, and so on) to stop reading a system. Off means off: what that system returned, and the answers written from it, leave the conversation with it, so the next question is not answered from a system nobody is reading. Attach it again to start afresh. The one exception is said in the question itself: read the other nodes with this connection’s credentials lets a database question reach the other nodes of the attached cluster, at the addresses the attached node reports and with its own credentials, never through a saved connection.
What happens first
Verbiqo first tells a plain ask from an investigation, by the words of the question. A plain ask wants something the system holds: a list, a size, a count, a version, a setting (find all databases and their sizes, what is max_connections set to?). Verbiqo reads only what the question names, the model reads the rest itself, and anything Verbiqo noticed on the way is kept apart under Also noticed. The step reads:
Understood: a plain ask; the model reads what it needs.An investigation asks what is wrong, why, what happened or what to change. For a database, Redis, Elasticsearch or Kubernetes, Verbiqo then asks the model one short question before it reads anything: which areas the question is about, what it names, and whether it is about now or about something that happened. Verbiqo decides every read itself and runs the areas’ checks before the model writes a statement:
Understood: live, performance; about shop.(by Verbiqo’s own rules) after Understood means the model did not answer in time or gave nothing usable, and Verbiqo chose the areas from the words in your question instead. The answer is the same kind either way. The model’s plan simply catches questions the word rules would miss. Prometheus and Splunk have their own investigation steps, shown the same way.
Before the model writes a statement, Verbiqo hands it the real columns of the server’s statistics views at its version (PostgreSQL, MySQL and SQL Server), when the model’s context window is 8,192 tokens or more. A statement that still names a column the server lacks is refused with the columns it has, and costs nothing. What was read is written by Verbiqo from the steps that ran: its own reads, the model’s statements, and anything refused or failed, so the answer cannot pass over a read that never happened. The window folds it under the answer, with the rest of what the answer rests on. The terminal prints it after the answer. An answer Verbiqo could not reconcile with the results carries a note saying so.
How to ask
A good question names three things. The more of them you give, the less Verbiqo has to assume.
| Say | For example | If you leave it out |
|---|---|---|
| What: a service, cluster or host | the MySQL servers, the payments service, db01 | Verbiqo asks which one you mean, unless the question is about everything, like is anything down? |
| When | last night, since 9am, on Tuesday between 2 and 4 | Verbiqo picks a recent period. The answer always shows the exact times it used. |
| What you want: a measurement or a cause | how high, what was the peak. Why, what caused it, root cause | Verbiqo judges from your wording. Words like why or root cause make it look for a cause. |
Each system has its own hints. For Splunk, naming the index and the shape of the answer matters most: Getting faster, better answers.
Example questions
| You want | Ask |
|---|---|
| A measurement | How was CPU on the MySQL servers over the last six hours? |
| A peak | What was the highest memory use on db01 yesterday? |
| A cause | Why did the payments service slow down yesterday afternoon? |
| Current state | Is anything down right now? |
| From logs | What errors did the checkout app log in the last 3 hours? |
| From a database | Why is this replica falling behind? |
More questions for each system: PostgreSQL, MySQL, SQL Server, Redis, Elasticsearch and OpenSearch, Kubernetes, Prometheus, Splunk. The security review and security logs.
When Verbiqo asks you something
If a name could mean more than one thing, or a time is unclear, Verbiqo asks rather than guesses. Nothing is read until you choose.
- Prometheus asks with a Did you mean and the choices it found. Reply with one of the choices as written, all to include every choice, or a clearer time, such as yesterday 2pm to 4pm.
- A database, Redis, Elasticsearch or Kubernetes asks when the name you used matches several things it knows. Kubernetes, for example: Which checkout do you mean? There are 2 in this cluster: shop/checkout, staging/checkout. The app shows the choices as buttons. The terminal numbers them and says Type a number. Choosing one asks your question again with that name made exact. You can also ask something else instead.
- Splunk asks when nothing in the deployment matches the name. It lists the likeliest of what the indexes hold, read from the deployment: host groups, source files, and application names inside the events. With an index named, everything in the index is also a choice. Reply with a number, a name, a word that picks some (checkout), or all of them. The same question then runs on those, over the same period.
Follow-up questions
Keep asking in the same window. A follow-up keeps the same systems and time unless you name new ones.
- continue carries on the same investigation.
- what about memory? asks about something else, same hosts, same time.
- in that window or at that time keeps the previous time exactly.
A follow-up about an attached database, Redis, Elasticsearch or Kubernetes cluster reads it again, and the fresh reports replace that source’s earlier ones in the evidence, so an old result cannot colour a new answer. Prometheus keeps a ledger of what it has measured across the conversation, so continue can build on it. To start something unrelated, ask about a different system or time, or type /clear.
Reading the answer
Each answer shows:
- What was checked, for which hosts, and the exact time range each check covered.
- The measurements the answer is based on. Verbiqo’s findings come from these. The explanation above them is written by your model. Verbiqo checks its figures and some of its claims against what it read where it can, and marks or removes what does not match.
- What could not be checked: hosts that are not monitored, that were down, or that had no data in the time asked about. Missing data is not the same as nothing wrong.
- The time range each check covered. Compare it with the time you meant, especially across time zones. Ask again with an exact range if they differ.
An answer is a starting point. A diagnosis can be incomplete or wrong. Check the measurements it shows before acting on it. An investigation can also end without a single cause, for example when the problem has passed or the data does not cover it. That is a valid answer, and it says what to look at next.