Fork me on GitHub
#portal
<
2023-09-14
>
John Doe17:09:11

Recently discovered the mulog+portal combination, it is pretty cool. I'm wondering if I can run some custom query to gather some metrics(counter for example) from the portal sink? For example, if I publish mulog to cloudwatch, I can query the data like stats count(*) by app-name, mulog/event-name to gather matrics and insights, can I do the same with portal data?

seancorfield17:09:17

Do you mean running queries across the atom containing the list of history (results) that Portal retains?

John Doe17:09:02

yes, basically run query code on all history portal results, not sure if this is a valid use case:grinning:

djblue17:09:05

So the easiest thing here might be to register the query function as a Portal command, something like (portal.api/register! #'my.query/fn) , then you can select the list and run the command via the command palette. Is that the type of UX you had in mind?

seancorfield17:09:57

You can also control the atom (containing the history list) that Portal uses at startup so you can treat it just like regular Clojure data: https://github.com/seancorfield/vscode-calva-setup/blob/develop/calva/config.edn#L44-L90

👍 1
seancorfield17:09:49

I have a REPL snippet to run arbitrary code on the most recent tap>'d value in Portal as well (see Tap Input Code immediately after the segment linked above).

djblue17:09:33

The custom atom approach also has the benefit of allowing you to automatically compute these metrics as you accumulate logs

djblue17:09:52

(def logs (atom {:metrics {}
                 :logs ^{:portal.viewer/default :portal.viewer/table} []}))

(defn submit [log]
  (swap! logs
         (fn [{:keys [metrics logs]}]
           (let [logs (conj logs log)]
             {:metrics (compute-metrics logs)
              :logs logs}))))

(portal.api/inspect logs)

seancorfield17:09:48

@U1G869VNV I was just looking over the Portal code -- I don't think the default values atom is easy to get at, right? So you pretty much have to use a custom submit and your own history atom for this...

John Doe17:09:33

Yeah, I think the Sean's custom atom approach is pretty much what I need. I'm quiet new to portal so I haven't tried the register function yet, I'll look into that as well. Is there api to just get the default atom instead of create a custom one?

djblue17:09:01

Yeah, the default tap list atom is private since messing with it could break assumptions the default submit function makes

John Doe17:09:19

ah, i see..

seancorfield17:09:41

You could provide a history function in the API perhaps, that returns the current contents of that atom?

1