logdetective as cli for interaction with logdetective.com service

[xsuchy]

Several people already asked me for this feature:

logdetective as cli tool should be able to submit the URL to logdetective.com/explain and display user the result.

I, personally, would love to see this as opt-in (i.e. not default behaviour). Likely triggered by option (--use-service).

The benefit is that users does not need to download model (not always possible) and may get the answer faster than using local cpu.

[phracek]

Wow, that would be a fantastic feature for automatic detection log problems in our CI systems. We already have installed logdetective from PyPi, but sending failed logs to services and return results is excellent.

[jpodivin]

We would have to add some more arguments for authentication but it is easy enough.

[phracek]

I have installed it on our CI system, where the containers Apps&Stacks are running, logdetective binary over PyPi.
Now when the build is failing, I would like to send a failed log to a services and wait for analysis. And this analysis would be used as a part of our logs to easily find a problem.

Do you know what is the progress of this issue?

I would like to call something like logdetective -f <failed-log> --server https://log-detective/send/

How to do it?

[phracek]

E.g. I would like to send a failed logs from this pull request sclorg/s2i-nodejs-container#492 at the end of the tests like /usr/local/bin/logdetective <logfile_name> and I see this output:

/usr/local/bin/logdetective rhel8.log
INFO:logdetective:Loading model from fedora-copr/Mistral-7B-Instruct-v0.2-GGUF
ggml-model-Q4_K_S.gguf: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 4.14G/4.14G [01:05<00:00, 63.7MB/s]
INFO:logdetective:Getting summary
INFO:logdetective:Compression ratio: 0.11594202898550725
INFO:logdetective:Analyzing the text
INFO:logdetective:Log summary:

            Snippet No. 0 at line #55:

            Red Hat Enterprise Linux 8 BaseOS               3.0 kB/s | 282  B     00:00
            ================
            Snippet No. 1 at line #56:
            Error: Failed to download metadata for repo 'rhel-8-server-baseos-rpms': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
            ================
            Snippet No. 2 at line #57:
            Error: building at STEP "RUN dnf -y module enable nodejs:$NODEJS_VERSION &&     MODULE_DEPS="make gcc-toolset-13-gcc gcc-toolset-13-gcc-c++ gcc-toolset-13-runtime         libatomic_ops git openssl-devel python3.12" &&     INSTALL_PKGS="$MODULE_DEPS nodejs npm nodejs-nodemon nss_wrapper-libs which" &&     ln -s /usr/lib/node_modules/nodemon/bin/nodemon.js /usr/bin/nodemon &&     dnf install -y --setopt=tsflags=nodocs $INSTALL_PKGS &&     rpm -V $INSTALL_PKGS &&     node -v | grep -qe "^v$NODEJS_VERSION\." && echo "Found VERSION $NODEJS_VERSION" &&     dnf -y clean all --enablerepo='*'": while running runtime: exit status 1
            ================
            Snippet No. 3 at line #58:
            errexit on line 33, common/build.sh
            ================
            Snippet No. 4 at line #64:
            make[1]: *** [common/common.mk:87: 22] Error 1
            ================
            Snippet No. 5 at line #65:
            make[1]: Leaving directory '/root/sclorg/s2i-nodejs-container'
            ================
            Snippet No. 6 at line #66:
            make: *** [common/common.mk:76: build-serial] Error 2
            ================
            Snippet No. 7 at line #67:
            Shared connection to 10.31.46.107 closed.
            ================

Explanation:
[Snippet No. 1] : The build process failed to download the required repository metadata (repomd.xml) for the base RHEL 8 OS package repository.
[Snippet No. 2] : The build script attempted to install required dependencies, including Node.js, but it was unable to complete the installation due to the failed repository download in Snippet No. 1.
[Snippet No. 3] : An error occurred during the build process, causing the script to terminate with an exit status of 1.
[Snippet No. 4] : The make build process encountered an error while trying to build the project.
[Snippet No. 5] : The make build process successfully ended the build process when it encountered an error.
[Snippet No. 6] : The overall build process, which includes multiple targets, encountered an error during the build of the serial target.
[Snippet No. 7] : The build session was terminated, likely due to the completion of the build process and the closing of the SSH connection.

Recommendation:
To resolve the issue, the first priority should be to ensure that the system can access the required RHEL 8 base OS repository metadata. This can be done by checking network connectivity and DNS configuration. Additionally, it may be necessary to add the repository to the local system's configuration file, or use a different mirror if the current one is unreachable. Once the repository is accessible, the build process should be re-executed. If the issue persists, it may be necessary to consult the project documentation or community for specific build configuration issues.
Response certainty: 86.14%

It looks like it works, but I have to download fedora-copr/Mistral-7B-Instruct-v0.2-GGUF model which I don't know if it is the latest one logdetective model or if it model from someone else.

But the explanation looks good. Based on the data which I have sent. Is there any way how to specify that this log is related to containers category logs?

[jpodivin]

@phracek Yes this is the right model. We always have the default model set up to make things work well enough.

[phracek]

@jpodivin In our Testing Farm machine, we would like to analyze the failed container build logs, but nowadays we do not have enough memory.

 logdetective /tmp/2.4-rhel9.lJptWm
INFO:logdetective:Loading model from fedora-copr/Mistral-7B-Instruct-v0.2-GGUF
ggml-model-Q4_K_S.gguf: 100%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 4.14G/4.14G [00:42<00:00, 96.7MB/s]
ERROR:logdetective:Failed to load model from file: /root/.cache/huggingface/hub/models--fedora-copr--Mistral-7B-Instruct-v0.2-GGUF/snapshots/f8d679d67ad3e551f131ceff60a673d3a6ff4286/./ggml-model-Q4_K_S.gguf
ERROR:logdetective:You likely do not have enough memory to load the AI model

And I guess, sending the log to logdetective server will help us instead of downloading model and analyzing failure. I really, do not want to increase memory in our CI systems. It can cause future problems in Testing Farm itself from infrastructure point of view.

[jpodivin]

Yes. That's what I would do.

[phracek]

@jpodivin Can you please send me a link, where or how to send logs to logdetective page or backend server?

[jpodivin]

@phracek Sure. It's all in the README https://github.com/fedora-copr/logdetective?tab=readme-ov-file#server That is enough if you want to deploy the server yourself.