112 lines
7.1 KiB
TeX
112 lines
7.1 KiB
TeX
\chapter{Project Proposal}
|
|
\ChapterLabel{ProjectProposal}
|
|
\index{Inviscid}\index{Prometheus}\index{VictoriaMetrics}\index{observability}
|
|
|
|
\section{Inviscid: Simple Monitoring for Small Web Services}
|
|
Inviscid is a proposed customer-facing startup that helps small businesses
|
|
monitor the health and performance of their web applications. Customers would
|
|
use a dashboard to view availability, response times, request volume, and
|
|
error rates. The service would pair these measurements with plain-language
|
|
status summaries, such as ``Your website is responding slowly,'' to help
|
|
customers recognize problems without requiring extensive monitoring expertise.
|
|
|
|
The semester prototype will focus on one demonstration customer application,
|
|
building on our existing Node.js website. The broader startup concept is a
|
|
future direction; customer account management and support for multiple
|
|
customers are outside the initial prototype. Our current proof of concept is
|
|
the Dockerized Color Buttons website deployed on AWS, documented in
|
|
\ChapterRef{CloudDockerDeployment}. Monitoring and deployment automation are
|
|
proposed work rather than completed features.
|
|
|
|
\subsection{Sample Customer Task}
|
|
A customer opens the Inviscid dashboard to check their website's health.
|
|
During a controlled demonstration, we will generate normal traffic and then
|
|
introduce slow responses or failed requests in the sample application. The
|
|
dashboard should display the resulting changes in response times and error
|
|
rates, accompanied by a short status summary explaining the problem.
|
|
|
|
\section{Proposed Development and Operations Tools}
|
|
GitHub will provide source control and collaboration, and AWS will provide
|
|
the deployment environment. Table~\ref{Table:InviscidTools} lists the planned
|
|
stack. Entries marked undecided are candidates, not commitments; the team
|
|
may revise them as implementation requirements become clearer.
|
|
|
|
\begin{tabularx}{\linewidth}{L{3.2cm}Y}
|
|
\caption{Tentative Inviscid Tool Selection\label{Table:InviscidTools}}\\
|
|
\toprule \textbf{Purpose} & \textbf{Tool and status}\\ \midrule
|
|
\endfirsthead
|
|
\toprule \textbf{Purpose} & \textbf{Tool and status}\\ \midrule
|
|
\endhead \bottomrule \endlastfoot
|
|
Source control & GitHub; selected.\\
|
|
Application & Node.js and Express; proposed, building on the existing website.\\
|
|
Container packaging & Docker; selected.\\
|
|
Deployment & AWS EC2; selected for the prototype.\\
|
|
Metrics backend & Prometheus and single-node VictoriaMetrics; selected for comparison, final backend undecided.\\
|
|
Dashboard & Grafana or a simple custom dashboard; undecided.\\
|
|
Automated testing & Node.js's built-in test runner and a traffic-generation script; undecided.\\
|
|
Deployment automation & GitHub Actions for a manually triggered build, test, and deployment workflow; undecided.\\
|
|
Customer/settings database & Amazon DynamoDB, if persistent customer configuration is needed; undecided. Metrics will be stored in the selected metrics backend.\\
|
|
Security checks & GitHub Dependabot and automated dependency checks; undecided.\\
|
|
\end{tabularx}
|
|
|
|
Our longer-term goal is a deployment pipeline that can be initiated with one
|
|
button press. The proposal does not claim that this pipeline is implemented.
|
|
|
|
\section{Research Question and Planned Comparison}
|
|
\begin{quote}
|
|
How do Prometheus and VictoriaMetrics compare as metrics backends for
|
|
Inviscid's prototype in terms of configuration effort, dashboard integration,
|
|
query response time, and CPU, memory, and storage usage?
|
|
\end{quote}
|
|
|
|
We selected these tools because both can collect and query application metrics,
|
|
and VictoriaMetrics can scrape Prometheus-compatible endpoints. This allows
|
|
us to reuse the instrumented application while investigating different
|
|
backend implementations. Prometheus includes metric scraping, PromQL queries,
|
|
and alert-rule evaluation. VictoriaMetrics provides metric collection and
|
|
storage with MetricsQL queries; alert-rule evaluation uses a separate component
|
|
such as \texttt{vmalert}. Supported configuration options and query behavior
|
|
will be checked rather than assumed identical.
|
|
|
|
We plan to compare Prometheus with single-node VictoriaMetrics using the same
|
|
application, metrics, traffic workload, collection interval, retention period,
|
|
and equivalent AWS resources. Configuration effort will be documented through
|
|
setup steps and difficulties; dashboard integration through the work required
|
|
to display equivalent measurements. Repeated equivalent queries and controlled
|
|
traffic will support measurements of query response time and CPU, memory,
|
|
and storage usage. Results will apply to the tested prototype and workload;
|
|
we will not assume that either tool is faster or more resource-efficient.
|
|
|
|
\section{Preliminary SWOT Analysis}
|
|
Table~\ref{Table:InviscidSWOT} evaluates each tool independently in the context
|
|
of Inviscid. Strengths and weaknesses describe tool characteristics;
|
|
opportunities and threats describe possible circumstances affecting its use.
|
|
These are preliminary assessments, not measured experimental results.
|
|
|
|
\begingroup
|
|
\small
|
|
\begin{tabularx}{\linewidth}{L{2.2cm}YY}
|
|
\caption{Preliminary SWOT for Inviscid's Metrics Backends\label{Table:InviscidSWOT}}\\
|
|
\toprule \textbf{Category} & \textbf{Prometheus} & \textbf{VictoriaMetrics}\\ \midrule
|
|
\endfirsthead
|
|
\multicolumn{3}{l}{\small\itshape Preliminary SWOT (continued)}\\
|
|
\toprule \textbf{Category} & \textbf{Prometheus} & \textbf{VictoriaMetrics}\\ \midrule
|
|
\endhead \bottomrule \endlastfoot
|
|
Strengths & Established open-source ecosystem; built-in metric collection and alert-rule evaluation; expressive PromQL query language. & Simple single-node deployment; built-in metric collection and storage; flexible MetricsQL query language and multiple supported ingestion formats.\\
|
|
Weaknesses & Local storage is neither clustered nor replicated; operating at larger scales requires additional architecture. & Alert-rule evaluation requires a separate component; the single-node deployment depends on one server for availability.\\
|
|
Opportunities & Inviscid could extend monitoring to containers and infrastructure through its existing exporter ecosystem. & Inviscid could accept metrics from different customer environments through its supported ingestion formats.\\
|
|
Threats & Rapid growth in customer metrics could exceed available resources and increase operating costs. & Customers requiring uninterrupted monitoring could necessitate a cluster deployment, increasing infrastructure and maintenance costs.\\
|
|
\end{tabularx}
|
|
\endgroup
|
|
|
|
\section{Technical Sources}
|
|
The technical characteristics above are based on the following official
|
|
documentation, consulted October 6, 2026. Opportunities and threats are the
|
|
team's project-specific assessments. Specific tool versions will be recorded
|
|
when the comparison is implemented.
|
|
\begin{itemize}
|
|
\item \href{https://prometheus.io/docs/introduction/overview/}{Prometheus overview}: collection, queries, exporters, and alerting components.
|
|
\item \href{https://prometheus.io/docs/prometheus/latest/storage/}{Prometheus storage}: local storage limitations and remote storage interfaces.
|
|
\item \href{https://docs.victoriametrics.com/victoriametrics/}{VictoriaMetrics documentation}: single-node deployment, scraping, ingestion, MetricsQL, and supporting components.
|
|
\end{itemize}
|